tP comments dashboard

Sorted based on the number of comments given to others' PRs, but also showing comments on own PRs and other comments given.

[This page was last updated on Oct 23 2020]

I think we can remove this test case.


        // Keywords match phone and email, but does not match name

Should remove INVALID_ADDRESS and VALID_ADDRESS from constant declarations above as well.

Is there a particular reason as to why this test case was removed? Perhaps we can use a different invalid value instead of removing the entire test case.

Should probably remove the above


@FXML 

private Label address;

as well.


platform for tutors to handle all of their administrative matters.


- Tutor's Pet displays your upcoming lessons so that you will never forget about them again.

Not sure if this would sound more in line with the other points since the word 'your' was used in both the other.


- Tutor's Pet allows you to mark your students' attendance and participation for each lesson.

Nice catch!


    public static final String MESSAGE_SUCCESS = "Listed all students.";

Perhaps we can update the Tag examples to something that's more student-tutor relationship like. Maybe something like how the student is performing in class.

This line shouldn't change.

Similar here, would be good to update the example tags.

Would be good to update this test constant as well.

Command word should be in kebab case.

Command word should be in kebab case. Perhaps can change the title to "Listing all students within a class".

We should retain the generated table of contents instead of using simple bullet points.

I think the second add is redundant.

Ellipsis should remain outside of the square brackets since users need to repeat the prefix as well.

I don't think we are supporting the separation of CLASS_NAME from MODULE_CODE?

Need to remove the address field in this section as well and update the tag prefix.

Need to update tag prefix here as well.

I don't think name, telegram handle and email are optional fields.

We need to rethink the command syntax for this operation. The parsing of arguments will be troublesome in this format.

For now maybe we can leave this feature out of the UG.

Kind of weird I'm a Project Advisor in the project I'm working on. Maybe Lead Developer would make more sense, but I'll change that in my own AboutUs update later.


   * **`add`**`n/John Doe t/@johndoe e/johnd@example.com tag/student` : Adds a student named `John Doe` to the application.

The second example should include more than one tag to show the possible multiplicities.


  e.g. `[tag/TAG]…` can be used as ` ` (i.e. 0 times), `tag/student`, `tag/Average tag/TA Candidate` etc.


Format: `add n/NAME t/TELEGRAM_HANDLE e/EMAIL [tag/TAG]…`


Format: `edit INDEX [n/NAME] [t/TELEGRAM_HANDLE] [e/EMAIL] [tag/TAG]…`

Not sure if this is the best implementation since the /by prefix will have no values associated with it when parsed by the ArgumentTokenizer


* `list-students c/CS2103T Tutorial T10`


**Add Student** | `add n/NAME t/TELEGRAM_HANDLE e/EMAIL [tag/TAG]…` <br> e.g., `add n/John Doe t/@johndoe e/johnd@example.com tag/student`


**Edit Student** | `edit INDEX [n/NAME] [t/TELEGRAM_HANDLE] [e/EMAIL] [tag/TAG]…`<br> e.g.,`edit 2 n/James Lee e/jameslee@example.com`


**List Students in a Class** | `list-students c/CLASS_NAME`<br> e.g., `list-students c/CS2103T Tutorial T10`


| `* * *` | Tutor with many students | Store my students' contact info/emails | Contact them easily |


Links an existing student to an existing class in the application.


* `list` followed by `link s/1 c/2` links the 1st student in the application to the 2nd class in the application.

* `find Betsy` followed by `link s/1 c/2` links the 1st student in the results of the `find` command to the 2nd class in the application.


#### Linking a student to a class: `link`

Should we update the rest of the use cases to use full stops as well?

Hmm, I think summary should remain after the detailed explanation, since it serves so summarise the above mentioned information.

In and A shouldn't be capitalised in the title.

I think we should retain the present participle form of the verb? The CS2101 set of slides for "Writing User Guide" also seems to favour retaining the present participle form of verbs, although it does not seem explicitly mentioned.


* 3a. No students found.

Would be good to mention that it is a message, otherwise might be confusing how to show an absence of something.

Should we keep it consistent and use delete instead of clear?

Technically Tutor's Pet can return more than one student found, so maybe it would be good to mention that it shows all matching students.

Applies to finding classes as well.


## Command overview


#### Clearing all students : `clear-student`


#### Clearing all classes : `clear-class`


| UC13        | Link a student to a class        |

| UC14        | Unlink a student from a class    |


**Use case: UC14 - Unlink a student from a class**


**Use case: UC13 - Link a student to a class**


| UC12        | Clear all classes                |

| UC13        | Link a student to a class.       |

| UC14        | Unlink a student from a class    |


        assertParseFailure(parser, NAME_DESC_BOB + VALID_PHONE_BOB + EMAIL_DESC_BOB,


        assertParseFailure(parser, VALID_NAME_BOB + PHONE_DESC_BOB + EMAIL_DESC_BOB,


        assertParseFailure(parser, NAME_DESC_BOB + PHONE_DESC_BOB + VALID_EMAIL_BOB,


    public static final String MESSAGE_SUCCESS = "All students in Tutor's Pet have been cleared!";

Perhaps we can rename this to getAddStudentCommand(Student student)


    public void parseCommand_editStudent() throws Exception {


    public void parseCommand_deleteStudent() throws Exception {


    public void parseCommand_addStudent() throws Exception {


    public void parseCommand_clearStudent() throws Exception {


    public void parseCommand_findStudent() throws Exception {


    public void parse_validArgs_returnsFindStudentCommand() {


    public void parse_validArgs_returnsDeleteStudentCommand() {

I don't think we should allow the explicit setting or getting of UUID in EditStudentDescriptor since it would then no longer be editing the same student.

The editedUuid should always be that of the studentToEdit.

I think it would be good to set a default UUID for each student in the tests and not rely on randomly generated data. This way it would be more predictable and testable.

I don't think there is a need for EditStudentDescriptor to have a uuid field.


        requireAllNonNull(uuid, name, phone, email, tags);

It would be good to edit the constructors in the TypicalStudents file as well to ensure the test constants are truly identical.


    private static ModuleClass createEditedModuleClass(ModuleClass moduleClassToEdit,

            EditModuleClassDescriptor editModuleClassDescriptor) {


 * Parses input arguments and create a new EditModuleClassCommand object.


     * Parses {@code userInput} into a {@code StudentNameContainsKeywordsPredicate}.

There's quite a bit of overlap here, would be good to deduplicate into:


    public static final Index INDEX_FIRST_ITEM= Index.fromOneBased(1);

    public static final Index INDEX_SECOND_ITEM = Index.fromOneBased(2);

    public static final Index INDEX_THIRD_ITEM = Index.fromOneBased(3);


 * A utility class for ModuleClass.

Seeing this template always makes me feel like they have already foreshadowed that we should do undo/redo features.


 * Contains integration tests (interaction with the Model) and unit tests for


 * A UI component that displays information of a {@code ModuleClass}.

Since we seem to be standardising to capitalise UI.


    // Independent UI parts residing in this UI container

It should be A UI because in both user interface and UI the word/abbreviation is pronounced as though it starts with the consonant y.


 * A UI component that displays information of a {@code Student}.


    -fx-background-color: transparent, #274156, transparent, #274156;

I think it would be best to define the return type as Label since we do in fact return a Label.


     * Converts this Jackson-friendly adapted class object into the model's {@code ModuleClass} object.


     * Converts a given {@code UUID} into this class for Jackson use.


     * Converts this Jackson-friendly adapted UUID object into the model's {@code UUID} object.


     * @throws IllegalValueException if adapted UUID is null.

I think it would be a good idea to introduce some checks for invalid UUIDs since the user can go into the json file to edit entries manually.

I would agree with @junlong4321 on this, it would be good to isolate any possible failure to just students.

While in invalidClassTutorsPet.json, students would be useful in the future when we implement validation for students who are registered in classes.

I agree with @ruixuantan. It would be safer since users can head into the json save file and modify its contents manually.

I think if we are fine with breaking the abstraction barrier, in some sense we already have since we are dealing with UUID objects instead of strings, then it is okay to change all references to studentUuids instead, including in the model.

Naming here might be a bit confusing since uuid is a object type itself.


    private final String uuidString;


     * Constructs a {@code JsonAdaptedModuleClass} with the given class details.


     * Converts a given {@code ModuleClass} into a {@code JsonAdaptedModuleClass} for Jackson use.


     * @throws IllegalValueException if there were any data constraints violated in the adapted class.


     * Creates a {@code ModuleClassBuilder} with the default {@code Name} and empty {@code studentUuids} list.


    public static final UUID ALICE_UUID = ALICE.getUuid();

    public static final UUID BENSON_UUID = BENSON.getUuid();

Can these two methods be made private?

I would advise against adding the class names as Tags since it might confuse our first time users into thinking that linking students to classes would automatically add the classes as Tags.

Perhaps it would be a better idea to declare the students and classes as static members and then have the two methods return a list of the static members.

Also, I think the two getter methods can be made private.


        // different keyword -> returns false


     *

     * @throws ParseException if the user input does not conform the expected format.

NIT: It might be a good idea to leave a class or two for manual adding when testing.

nit


        FindModuleClassCommand expectedFindModuleClassCommand =

                new FindModuleClassCommand(new NameContainsKeywordsPredicate<>(Arrays.asList("CS1101S", "Tutorial")));



        // no leading and trailing whitespaces

        assertParseSuccess(parser, "CS1101S Tutorial", expectedFindModuleClassCommand);


     * Additionally, removes all {@code Student UUID}s in each {@code ModuleClass}.


    /**

     * Removes all {@code Student}s from the student manager.

     * Also removes all {@code Student UUID}s from each {@code ModuleClass}.

     */

Perhaps it might be a good idea to have the same name for both methods (in Model and in TutorsPet)?

Perhaps {@code Student UUID}s would be more accurate since {@code studentUuids} refers to the list itself rather than its contents.


    /**

     * Removes all {@code Student UUID}s from every {@code ModuleClass} in the class list.

     */

Is there any particular reason why we choose ClearModuleClassCommand as the different type as opposed to some other primitive type like an integer?




        model.deleteAllModuleClasses();


    private static final int NUMBER_OF_COLOURS = COLOURS.length;

Should we be using the American spelling of Colour instead?

I think we should retain the name listOfTags or tagList instead? Although the field was declared as static final, it is not exactly a constant in essence since the contents of the list can change.

I think it would be wise to follow the following categorisation of constants as given by the excerpt below from the Google Style Guide.


        requireNonNull(toCheck);



        return internalList.stream().anyMatch(toCheck::hasSameUuid);


        requireNonNull(student);



        return students.containsUuid(student);

Instead of reading students once again, perhaps we may want to use the existing information stored within tutorsPet instead?

We can also document this precondition in the JavaDoc to state that the tutorsPet passed in should have its students loaded prior.

Just wondering, is this "feature" extended to the native UUID stored in each JsonAdaptedStudent as well?


     * If Tutor's Pet encounters duplicate {@code Student UUID}s in a class, it will not load

     * duplicate {@code UUID}s into the model. Hence, Tutor's Pet should still boot up successfully.


     * Ensures that Tutor's Pet will not be able to boot up given an incomplete {@code UUID}.


     * Ensures that Tutor's Pet will not be able to boot up although Java tries

     * to pad missing {@code UUID} digits in broken {@code UUID}s with zeros.


     * Prevents Tutor's Pet from booting up if two or more {@code Student}s are found with the same {@code UUID}.

            "Invalid student(s) found in class(es).";

In view of the change, I would recommend changing the test case to remove a student that was not previously part of any class. This way, we would only be changing the student list and would be a better representation of the test case.

I'm slightly intrigued as to why 50?

Will we be supporting hyperlinks as venues given the current situation?

Perhaps it might better for these methods to take in LocalTime objects instead to remove any chances that a parse error is thrown.

Perhaps it would be good to test the equals method as well?

Same for the NumberOfOccurrences class.

Perhaps something along the lines of Add an attendance record of a student would be better? Similarly for the rest below?


Tutor’s Pet is a desktop application that helps Computer Science teaching assistants reduce the amount of time they spend on administrative tasks.

Or alternatively, perhaps this sentence can be written in a more user centric manner?

Perhaps it would be easier to support 24 hour time format (0800, 1000 etc.) first before thinking if we want to support other time formats?

command may not be the best word to use here since they do not see all commands executed, i.e. they only see commands that can be undone/redone. I suggest an alternative here, although I think it definitely can be further improved.


### View action history : `view-history`



View a list of actions that can be undone or redone.

The week seems to be missing from the description, same for the subsequent attendance record commands.

Agreed

The phrasing of this sentence is rather weird, especially the add students into those classes part. I have an alternative below, but open to better phrasing as well.


It allows teaching assistants to keep track of the students in their classes, and record their attendance and participation scores.```
</panel>

<panel header="**136 :octicon-git-pull-request::octicon-comment:** (commented on others PR)" popup-url="https://github.com/AY2021S1-CS2103T-T10-4/tp/pull/110#discussion_r504329388" expanded cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf">

```suggestion
*  `edit-attendance c/1 l/1 s/1 w/1 p/10` Edits the 1st week's participation score of the 1st student of the 1st lesson of the 1st class to 10 points.

| **View Action History**           | `view-history`                                                                                                                                                            |

I don't think week 0 is officially supported.


* The `WEEK` **must be a positive whole number** 1, 2, 3, …


* The `WEEK` **must be a positive whole number** 1, 2, 3, …


* The `WEEK` must be a positive whole number** 1, 2, 3, …

* The participation score **must be a non-negative whole number** 0, 1, 2, …


* User has to specify at least 1 field (DAY/START_TIME/END_TIME/VENUE) to be changed.

Just noticed this, but perhaps this should be use case ends since it has been deemed that the lesson already exists?


      Use case ends.

Seems like this was inherited from previous versions.


1.  User requests to delete a specific attendance record.

Since the command expects multiple correct indexes, would it be more appropriate to phrase it as One or more of the given indexes are invalid.?

That's true, I think we can keep the current version.

I think it would be best for these to be left to be handled by the logic part of the house for consistency with the rest of the model components. It would be sufficient to provide getter methods and a suitable constructor.

Similarly, these methods should be reserved for the commands in logic to handle to better decouple the model from the controller/logic.

Instead of introducing this method within the model, perhaps it would be better for the methods that require a zero based number to use the currently available Index object and retrieve a getOneBased() value instead?

That is, the method that does the comparison should be the one performing the conversion from a zero based index to a one based index for comparison with the Week value.

Perhaps we should take in Index instead of int for week associated values (at least for this class since it sort of acts like an index to a list) so that there is less room for mistakes of getting the base wrong in the future?

Or since the Week class seems to be unused, perhaps the Week class can be used to store a valid (i.e. within 1 and 52 when counted from base 1)Index object. And the Week object can be used as the definitive way to check for validity and retrieve AttendanceRecord objects from the appropriate week/index.


     * Inserts a new {@code UUID} and {@code Attendance} into the {@code AttendanceRecord} we are building.

This class seems unused, but perhaps we can convert it to store an Index while performing validation on the Index value.

This way, we can ensure that there will be no ambiguity when parsing, transferring or retrieving values based on weeks.


     * Returns true if the given week is an integer between {@link NumberOfOccurrences.LOWER_BOUND}

     * and {@link NumberOfOccurrences.UPPER_BOUND}.


 * Guarantees: immutable.


     * Returns the {@code Attendance} of the given {@code Student UUID}.


 * Guarantees: immutable.

This shouldn't be necessary anymore right?


     * Returns the {@code Attendance} of a {@code Student} in a particular {@code Week}.


     * Returns the {@code AttendanceRecord} of a particular {@code Week}.

The changes might cascade into the other tests as well.


    public static final int VALID_WEEK_VALUE_5 = 5;

    public static final int VALID_PARTICIPATION_SCORE_33 = 33;

    public static final int VALID_PARTICIPATION_SCORE_51 = 51;

    public static final int VALID_PARTICIPATION_SCORE_80 = 80;


        // invalid score

        assertFalse(Attendance.isValidParticipationScore(Attendance.LOWER_BOUND - 1));

        assertFalse(Attendance.isValidParticipationScore(Attendance.UPPER_BOUND + 1));

        assertFalse(Attendance.isValidParticipationScore(-1));



        // valid score

        assertTrue(Attendance.isValidParticipationScore(Attendance.LOWER_BOUND));

        assertTrue(Attendance.isValidParticipationScore(Attendance.UPPER_BOUND));

        assertTrue(Attendance.isValidParticipationScore(10));


        Index invalidWeek = Index.fromOneBased(Week.UPPER_BOUND + 1);


            if (!lesson.equals(lessonToDelete)) {


    public static final Prefix PREFIX_START_TIME = new Prefix("st/");

Perhaps this might allow more versatility for this method? Or alternatively it could be mentioned in the method description that it will always assume a class index of one.


    public static String getAddLessonCommand(Index moduleClassIndex, Lesson lesson) {

        return AddLessonCommand.COMMAND_WORD + " "

                + PREFIX_CLASS_INDEX + moduleClassIndex.getOneBased() + " "

                + getLessonDetails(lesson);

    }

Not too sure about this, but "Days" sound slightly better? Or perhaps can consider using "The day...", but it might not sit too well with the other constraint messages.


    public static final String MESSAGE_CONSTRAINTS = "Days must be typed out fully in capital letters.\n"


     * The {@code String} must be capitalized and be spelt exactly as each enum value.

     *

     * @throws InvalidDayException if the {@code String} does not match any of the enum values.

Perhaps we can simplify this method to:


    private boolean hasDuplicateLessons(List<Lesson> lessons, Lesson lessonToCheck) {

        return lessons.stream().anyMatch(lessonToCheck::isSameLesson);

    }


     * Converts the contained {@code List<JsonAdaptedUuid> studentUuids} to a {@code List<UUID>}.


     * Converts the contained {@code List<JsonAdaptedLesson> lessons} to a {@code List<Lesson>}.


        List<UUID> studentUuids = getUuidList();

        final Set<UUID> studentUuidSet = new HashSet<>(studentUuids);


        return new ModuleClass(modelName, studentUuidSet, lessonList);

Could we split this into a separate test case since we are testing for a failure here?

Would be good to update the JavaDocs with the appropriate details.

Could we test for a null lesson as well? Perhaps in another file nullLessonTutorsPet.json and this file can be renamed nullStudentUuidsTutorsPet.json.

Could we test both versions of JsonAdaptedLesson creation? That is have another test case that creates the JsonAdaptedLesson solely using the individual details of the Lesson rather than the object itself.

Nice thanks!

We need to perform some checks to ensure that the student is a member of the moduleClass as well.

This seems to appear quite a few times around the code base, could this be placed into another class, perhaps the ParserUtil, or any other suitable class and the rest can reference this public method instead.

Could we include a test for a null Week as well?

It seems like the expected vs actual fields are swapped? It might be good to also declare the parser version as the command and the AddAttendanceCommand version as expectedCommand?

Perhaps we should have a test for the case where the student is not a member of the class?

I think typically there are spaces both before and after the : in enhanced for loops?


    public static final String MESSAGE_MISSING_STUDENT_ATTENDANCE = "Student's attendance does not exist";

Nice check

Just noticed this, but could have probably used .getOneBased() > lastShownStudentList.size() to drop the equality sign. Not important though.

For some of the tests here, it might be good to add simple assert statements to make sure that certain assumptions about the model are true. For example the studentNotInClass, execute_success, noStudentAttendance tests rely on the fact that the TypicalTutorsPet provided meet certain criteria.

Should we check if the attendance we want to delete exists in the first place?

It might be a good idea to display an error message instead of showing a success message if the attendance did not exist.

In AddAttendanceCommand, parseWeek seems to throw the Week constraint message instead of the usage message when it fails. Perhaps we should keep it consistent.

I think this appeared in AddAttendanceCommandTest previously. Instead of duplicating it, perhaps we can make it public in the other class for others to use. It can also be moved to another more suitable location, especially as it seems like these helper methods are becoming more common.


            + "Note: All indexes must be positive integers.\n"

[Redacted: non-issue]


            + PREFIX_WEEK + "WEEK_NUMBER (must be a positive integer)\n"

I think it would be good to state the main purpose of the method first before providing additional details.


     * Adds {@code attendanceToAdd} to {@code targetLesson}.

     * All existing {@code Attendance}s in {@code targetLesson} are copied to the new {@code Lesson}.


     * @throws CommandException if an {@code Attendance} already exists for the {@code targetStudent} in the {@code targetWeek}.


     * @throws CommandException if the {@code Attendance} of the {@code targetStudent} in the {@code targetWeek} does not exist.


     * Removes the {@code Attendance} of the {@code targetStudent} in the {@code targetWeek} from the {@code targetLesson}.

     * All other existing {@code Attendance}s in {@code targetLesson} are copied to the new {@code Lesson}.

Perhaps we should first check that the student is a member of this class before proceeding further?

Nice job extracting these methods to a separate class.

Since they are public methods now, perhaps we should have unit tests for them? It can come in a separate PR subsequently though.




        // delete week 1 attendance record

        Map<UUID, Attendance> record = lesson.getAttendanceRecordList()

                .getAttendanceRecord(targetWeek).getAttendanceRecord();

        Map<UUID, Attendance> updatedRecord = new HashMap<>(record);




        Lesson modifiedLesson = new LessonBuilder(lesson)




        // delete non-existent week 5 attendance record

        Map<UUID, Attendance> record = lesson.getAttendanceRecordList()

                .getAttendanceRecord(targetWeek).getAttendanceRecord();

        Map<UUID, Attendance> updatedRecord = new HashMap<>(record);




        Lesson modifiedLesson = new LessonBuilder(lesson)


     * Adds {@code lessonToAdd} to {@code moduleClassToAddTo}.

     * All existing {@code Lesson}s in {@code moduleClassToAddTo} are copied to the new {@code ModuleClass}.

Perhaps we should also change moduleClassToAddTo to targetModuleClass for consistency?


     * Replaces the {@code lessonToEdit} with {@code editedLesson} in {@code targetModuleClass}.

     * All other existing {@code Lesson}s in {@code targetModuleClass} are copied to the new {@code ModuleClass}.


     * Removes the {@code lessonToDelete} from the {@code targetModuleClass}.

     * All other existing {@code Lesson}s in the {@code targetModuleClass} are copied to the new {@code ModuleClass}.

Can I check how does this defer in purpose from createModifiedModuleClassWithEditedLesson?

Perhaps we can follow the existing statements and use a single statement that all indexes must be positive integers.

        boolean isStudentIndexPresent = argMultimap.getValue(PREFIX_STUDENT_INDEX).isPresent();
        boolean isWeekPresent = argMultimap.getValue(PREFIX_WEEK).isPresent();
        if (!isModuleClassIndexPresent || !isLessonIndexPresent || !isStudentIndexPresent || !isWeekPresent) {


        boolean isModuleClassIndexPresent = argMultimap.getValue(PREFIX_CLASS_INDEX).isPresent();

        boolean isLessonIndexPresent = argMultimap.getValue(PREFIX_LESSON_INDEX).isPresent();

        boolean isStudentIndexPresent = argMultimap.getValue(PREFIX_STUDENT_INDEX).isPresent();

        boolean isWeekPresent = argMultimap.getValue(PREFIX_WEEK).isPresent();



        if (!isModuleClassIndexPresent || !isLessonIndexPresent || !isStudentIndexPresent || !isWeekPresent) {

@junlong4321 Actually, for such a case where the Boolean variables are only used in the guard clause, shouldn't they be part of the block for the guard clause?

There seems to be one more occurrence at line 37 in this file.

Should this and the following points be relocated to the Using Tutor's Pet section?

Should this be Classes and Students instead since the application uses those words instead?


 students in Tutor's Pet, make use of the **`list-student`** command.


Gives you an overall summary of a student's attendance and participation scores.

Perhaps a more user-centric phrasing can be used here?


    ![Delete lesson after](images/ugimages/DeleteLessonAfter.png)


A `UUID` is a unique 128-bit number to identify a unique `Student` within Tutor’s Pet.


`Student` `UUID` will help to ensure referential integrity of `Student` data across different models when

`Student` data is modified by the user.

Maybe you could mention that another con is the very low, but still present, risk of a collision when generating random UUIDs.


  * Cons: The `Email` field is editable while the unique identifier of each `Student` should not be editable to prevent the need to cascade a change in the identifier of the `Student`.

I think we should include style.puml across all our diagrams to ensure consistency?

Based on the textbook, there seems to be a colon before the class name even for calls to static methods.

participant "<<Class>>\n:ModuleClassUtil" as ModuleClassUtil LOGIC_COLOR
participant ":ModuleClass" as ModuleClass LOGIC_COLOR
participant "<<Class>>\n:LessonUtil" as LessonUtil LOGIC_COLOR
participant ":Lesson" as Lesson LOGIC_COLOR
participant "<<Class>>\n:AttendanceRecordListUtil" as AttendanceRecordListUtil LOGIC_COLOR

Perhaps this line isn't necessary since the association has been represented as a field already? I'm not too sure on how maps should be represented as well. We should probably check with Prof Damith for clarification.

It contains the `Attendance`s of all `Students` who have attended the particular lesson.

Or perhaps we can rephrase the sentence since the above does not get rendered as nicely?

Hmm I'm not sure if we should have the colon here?


If you would like to add a lesson to a class, you can make use of this command.


* You receive news that you will be teaching `CS2103T Tutorial` on `Tuesday 10:00-11:00` at `COM2 #02-02` from week 1 to 13. Hence,


* You have one less lesson to teach now.


If you would like to delete a specific student's attendance from a lesson, you can make use of this command.


* Alice's attendance for week 1 has been deleted.


* You would like to delete Alice's attendance for the Thursday 10.00am to 11.00am lesson of CS2103T Tutorial in Week 1.

Hence, you type in the command `delete-attendance c\1 l\1 s\1 w\1` and press <kbd>Enter</kbd>.

I think every command should be part of a sub category of features?


#### Display Statistics : `stats`

Would it be possible to move private methods to the bottom of the class so that it can be grouped with the rest of the private methods?


    /**

     * Returns an {@code AttendanceRecord} where the {@code Attendance} of the {@code studentToRemove} has been removed.

     * If the {@code studentToRemove} does not exist in the {@code attendanceRecord}, the {@code attendanceRecord} is returned unchanged.

     */

    private static AttendanceRecord removeStudentFromAttendanceRecord(


    /**

     * Returns an {@code AttendanceRecordList} where the {@code Attendance}s of the {@code studentToRemove} have been removed.

     */

I think this line can be simplified?


            tp.addModuleClass(moduleClass);

Same as above,


            tp.addModuleClass(moduleClass);

Perhaps we could shift the responsibility of removing the student from module class to the command instead. Since there is currently no existing dependency from model to logic, it might be best to keep it that way to remove this cyclic dependency between the packages?

One suggestion would be for the delete and clear student commands,we can retrieve the ReadOnlyTutorsPet from the model and perform the mapping function there, and then set the new TutorsPet back into the model.

@ruixuantan do you have any suggestions on how this cyclic dependency can be resolved?


    /**

     * Returns a {@code Lesson} where the {@code Attendance}s of the {@code studentToRemove} has been removed.

     */


     * Returns an {@code AttendanceRecordList} where the {@code Attendance}s of all {@code Student}s have been removed.


     * Removes the {@code studentToRemove} and all associated {@code Attendance}s from the {@code targetModuleClass}.


     * If the {@code studentToRemove} does not exist in the {@code attendanceRecord}, the {@code attendanceRecord}

     * remains unchanged.


    public void removeStudent(Student student) {


    public void removeAllStudents() {

I think I spotted a typo in the other Cards as well, could you help to change them as well?


     * Creates a {@code LessonCard} with the given {@code lesson} and index to display.

TIL, didn't know that.

Quite interesting explanation here also: English StackExchange

The JavaDoc was adapted from an equivalent JavaDoc in UniqueStudentList.

I would be more inclined to retain both in their current expressions.

This JavaDoc was directly adapted from a corresponding JavaDoc in the existing UniqueStudentList class as well. As such, I would be more inclined to retain the current expression since it is consistent with existing code.

The backing list refers to the internalList while unmodifiable means that any attempted modifications on the list would result in an UnsupportedOperationException being thrown.


        // workaround as storage functionality for ModuleClasses has not been implemented


        // workaround as storage functionality for ModuleClasses has not been implemented

Agree with @junlong4321 for consistency.

This JavaDoc was directly adapted from a corresponding JavaDoc in the existing UniqueStudentList class, so I would be more inclined to retain the current expression since it is consistent with existing code.

As these informal list points are not complete sentences and are fragments, I would be more inclined to leave the full stop out?

Oops, that slipped through my manual search and replace.

I think for this case, it would be okay to not include an empty line above the comment since it is the first line in the method body. It will also be more in line with existing code.

Good idea, added in!

Resolved instead by changing to lowercase throughout, more in line with comments found above.

Because of the need to include the CURRENT_INDICATOR for a particular entry, which is rather specific to ViewHistoryCommand, the method in StringUtil would be oddly specialised for a method in the commons package.

Instead, I think I would abstract out the creation of the message to a helper function that resides within the ViewHistoryCommand class.

I've included this spacing to separate code used to set up the environment (above) from the code that is being tested (below).

The cache is used in the following scenario:

The user has some previous commands already saved in the history.
The user partially types a command string, but decides to refer to a previous command.
The user recalls the previous command for reference but wants to return to the partially typed command.
The user can retrieve his partially typed command string from the cache.

I've also included some logging functionality at the info and fine levels.

Hmm I wanted to differentiate this constructor from the previous as this constructor is typically not meant to be used to create new lessons, but rather act as a "copy" constructor with modifications. Would it be better to leave it as is, add the word "new", or "Creates a copy of a lesson with the specified parameters."?

I did consider the direct de/serialisation of key-value pairs using the Jackson, however I was rather hesitant to use it as I was unsure how it would play with the current implementation of JsonUtil. Similarly, the StudentAttendance implementation was used to avoid the need to complicate the deserialisation of key-value pairs.

I do agree with you that the direct serialisation would be more intuitive and provide a one to one mapping with the actual classes in the model.

I'll be inserting another diagram over there (around line 280) to explain the case when the current value is cached in a subsequent PR. So I think I'll leave the summary at the end for now.

Can you rebase and then should be good to go.

Not sure if we need to get approval before we merge this in since we are trying to use a new module?

This seems to be missing the saving of UUIDs to local storage, is that planned for a separate PR?

Closed with #61.

Closed with #62.

Resolved in #68.

Closed with #55.

@ruixuantan could I also get your opinion on the test cases written for the new features?

Closed in #131

@ruixuantan This PR only adds unit tests for LessonUtil since they were updated. I'll leave #158 open until unit tests have been added for ModuleClassUtil.

Non-issue since users can use stats to see if a week has an attendance record and use find attendance to view the specifics.

I'm not sure if &gtins> is the correct tag to use here? (And the closing tag should be &gt/ins> right) From what I gathered online &gtins> is to underline some text in html to indicate it is an insertion, but there's not &gtdel> tag here, so I think it might be more appropriate to use either the &gtu> tag for underlining or []() syntax if its supposed to be a link

I think we should retain the step of copying our jar file over to the folder the user wants to use as the home folder, as we'll need to do saving in a data folder as well

There's inconsistency between this and the description of the help command below. Also, I think the help contents will be opened in a window and not a page?

Refer to comment above

Maybe we should change PHONE to PHONE_NUMBER, following the original format, for clarity


Shows commonly used commands for TBM.


* Role: In charge of deliverables and deadlines

Following the format for client delete INDEX, maybe add a short one line statement to explain what this command does?

Same as prev comment, and there's also an extra newline here that I think would be better to remove

The indexing is off here

Indexing off here too


* 1a. The list of clients is empty.

Might want to change this to match the original "Finds clients whose names contain any of the given keywords.", and change n/NAME to KEYWORD [MORE_KEYWORDS] as the format section below mentions keywords


* The search is case-insensitive. e.g `hans` will match `Hans`

* The order of the keywords does not matter. e.g. `Hans Bo` will match `Bo Hans`

* Only the name and country are searched.

* Only full words will be matched e.g. `Han` will not match `Hans`

* Persons matching at least one keyword will be returned (i.e. OR search). e.g. `Hans Bo Russia` will return `Hans Gruber`, `Bo Yang`, `Alice Katya`


### Listing all clients: `list`



Shows a list of all clients in the address book.


Finds clients whose names contain any of the given keywords, or whose country of residence contains any of the given keywords.

I think we should just stick to either the abbreviation TBM or the full name in the headers, not both

either that or perhaps change both back to the simple "User Guide" and "Developer Guide". I don't really see a need to have TBM in the title, as the whole website is already about TBM, plus we have introductions and our home page.

Just to add on, I don't think the &gtins> tag should be used here, as markup defines it as inserting something? e.g. here. &gtu> seems more appropriate if the intention is to underline the text.

LGTM


        this.countryName = new Locale("", countryCode).getDisplayCountry();

I think its more intuitive to call this specific method


    private final String COUNTRY_NAME;

    private final String COUNTRY_CODE;

    private final ArrayList<Note> COUNTRY_NOTES;

From the convention guide: Constant names must be all uppercase using underscore to separate words. I'm not sure if countryNotes should be marked final actually, since we are going to modify it in the addCountryNote function.

Also, I feel that the notes should be stored in something like a LinkedHashSet, since we don't really want to add in duplicate notes, and its easier to check if its a HashSet.

I feel like we shouldn't initialize countryNotes until it is actually needed. E.g. Only when the user actually adds a country note, or there are notes for this country in the save file. If not its unnecessary overhead, especially if there are many countries.

Not sure how the rest think @tankangliang @rtshkmr @LeeEnHao

Constant names must be all uppercase using underscore to separate words.

Is there a need for this Map? From what I see, I think we can just keep the ISOCountry String array, then check if the entered String is inside, before initializing a new Locale with that String. This way, we won't have to keep so many country objects, since most of the countries likely won't be used.

Constant names must be all uppercase using underscore to separate words.

Ah ok nvm I think can just stick with this for now. I was thinking of something else to prevent the unnecessary creation of objects, but this HashMap is still necessary for it, my bad.

Btw can change the HashMap to Map, so that we standardize

Hmmmm seems like by constant they mean static final only. Static only or final only aren't counted as constants, even though one of the examples in the website has an example of final only variables being set to all caps + underscores.

No need to change bah

Would be better to standardize with the other commands, for example the ClientFindCommand.

Btw, ClientFindCommand doesnt have requireNonNull(predicate), I think can just add it in there too

There needs to be a javadoc comment here. (All public classes should have javadoc according to the textbook)

javadoc comment

requireNonNull

Might want to standardize with other equals methods. Basically these 3 parts: short circuit if same object, instanceof handles nulls, and state check. Can look at ClientEditCommand for an example

Maybe can add extracting out the messages into a static final string into the TODO: better messages, in case we forget

javadoc comment

Might want to add a TODO here

This whitespace is little bit weird lol, but might just be my personal preference

here too

Might want to change the predicate name to ClientCountryMatchesInputCountryPredicate for clarity?

might wanna change this equals to match the 3 step thing

Probably should calculate and return the hashcode using noteContents, since I think Note is already being used hashed objects

Would suggest changing this to isValidCountryCode, for clarity

Hmmm I was thinking that this CountryManager class holds all Country objects, while every other class should be holding references to these objects instead of any new Country() object. That way, the class themselves should be able to check if the Country has any notes, and this method would not be needed.

Can help to update the parser names for the delete and find command?

Should probably add in a hashCode() function just in case

Actually for this toString, should we be returning countryName instead? Maybe can add a comment to address why we're returning countryCode.

The whitespace is off

Add a comment for standardization


        // multiple countries - last country accepted

not sure about that, but later that guy forget lmao

I think we should just do it now man. From java docs: Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Yeah, but usually the purpose of the toString is to return a more "human readable" format of the object, so maybe countryName would be a better choice for the return value.

LOL ok then just fix it in that issue bah

Would be slightly clearer if you changed the variables names to SMALLEST_NEGATIVE_OFFSET and LARGEST_POSITIVE_OFFSET imo

Not sure why this sys print is here

Add new tests for timezone pls

We should catch NumberFormatException here, in case people enter a number that is longer than what an int can hold

Extra new lines, and I think the javadoc can be added already right

Would be better if MESSAGE_USAGE is moved upwards for organization purpose, so that public static final is above private static final

Also, its hard to read when the lines are separated so much with the random comment also, would suggest this:

(must be a positive integer should also be moved to the description, not inside the parameters)

Rmb to import PREFIX_NOTE


            + "Parameters: INDEX " + PREFIX_NOTE + "NOTE_STRING\n"

            + "Example: " + COMMAND_WORD + " 1 " + "client note content";

I think everything has to go through model, as it is being used for UI I think

This variable doesn't seem to be used, since you already removed the redundant code

agree with rayson

Would be good to remove the line break for readability

Would be good to move this down, after the if statement

Probably would be good to add a javadoc comment for this method as well

There is a need to implement the hashCode function, since note is being used in a hashSet.

Could you also change the equals method to match the 3 step thing? (1. short circuit if same object. 2. instanceof handles nulls 3. state check)

There's like extra newlines here and above as well

Extra newline

I would suggest that this is changed to a LinkedHashSet, as we will want the order of the notes to remain the same as the order they were added. HashSet does not guarantee order

I believe the country notes are also using LinkedHashSet

Also, I think it would be better if the clientNotes was initialized only if the client has notes, probably can add a TODO here to optimize this.

I think this variable still isn't being used

Other than that, LGTM


    public String getInputCountryStringRepresentation() {

Better to have descriptive function names without abbreviations imo

Probably can be on the same line for clarity

Would be better to move this above MESSAGE_DUPLICATE_COUNTRY_NOTE so that the public static final variables are tgt.

For this, it would be more concise to just use the overloaded constructor of ArrayList ArrayList(Collection&gt? extends E> c) to make the copy of the filtered client list

Either that or just initialClientList.addAll()

Would it be better to use an assertEquals here?

This can be moved out of the loop I think

The assertTrues and assertFalses here can probably be changed to assertEquals and assertNotEquals for better clarity

Ah ok I missed that

I think it would be better if clientParser accepts a Client instead of a generic Object, then do the casting here. This way, we wont have to do the casting + assertion inside clientParser.

Should these have more descriptive names?

Also, should include param/return tags in javadoc for this method

If this is a temporary method, should add in a TODO somewhere here to remove after its not needed. This method looks very un-OOP-like lolol

Should include params and return tags also in this javadoc

This method needs more explanation using comments/better descriptive names. For example, what is start to end order? Why is there the Math.min with the magic literal 14?

Would suggest extracting out the 14 as a private final static var

Also, I think it should be String... args and not String ...args? At least that's the format google java format uses

Sys.print shld be removed. Also, better explanation should be given in the comments/javadocs, and the variable names should be more descriptive. For example, what happens in the bigger picture if there is no null field that can be set?


public class WidgetModelManagerTest {

Also, extra newlines above this can be removed

Naming of test functions should follow the format

test functions should follow the format: featureUnderTest_testScenario_expectedBehavior()

e.g. sortList_emptyList_exceptionThrown() getMember_memberNotFount_nullReturned

test functions should follow the format: featureUnderTest_testScenario_expectedBehavior()

e.g. sortList_emptyList_exceptionThrown() getMember_memberNotFount_nullReturned

Also, probably should make all the tests public void to standardize

I feel like optional isn't needed in this file? It would be clearer if you do divs[X] == null ? "" : divs[X]

Is this sysprint leftover from debugging? Other than this, LGTM

This should be an assert / exception instead, since our countryNotesMap already contains all possible countries, and if there is a country not contained in our map, it should not have been created in the first place


* SUGGESTION_TYPE must be one of the following: `frequency`, `available` or `contract`

maybe change to command word suggest instead? Make it seem more like normal english

should extract these strings as static final vars

Should add a TODO here to do something in the execution

I think it's fine to leave it as a class for now, since if we change it to an enum it might be hard to integrate. Maybe can just KIV as a TODO.

This needs to be updated to the actual message constraints for note. Commands like "client note add 1 nt/" causes this to appear in the response box, which is a bug.

Would suggest a simple "Note should not be blank"

why are these protected? I couldn't find any other classes in the same package using them

Should return an unmodifiable set instead.

Since the equality checking was updated to include hasSameTags, the hashCode should be updated to ensure the tags are hashed as well, to maintain the contract between the equals and hashCode method.

Should return unmodifiable objects. Also, getCountryNote doesn't seem to be used, will it be used in a later commit?

This doesn't seem to be called in the program, will it be added in a later commit?

I think it would be better if we did a new ClientBuilder(ALICE).build();. The ALICE client itself should not be modified as it may affect other parts of the testing unexpectedly.


    void initMapFromClients_addClientWithTaggedNotes_success() {

This method doesn't seem to return a boolean, so success should be used instead. Or you could change it to doesNotThrowException. The other 2 methods below also need their method names updated, returnsTrue should be <expected outcome>.

Will need to add more tests, but can do in a separate issue probably.

Not sure why only this variable is static? Could probably make all of them just final.

Should probably test the other methods and constructor as well, but can be done later in a separate PR as its not that important for now.

Same comment as in TagNoteMapTest.java

Is this needed lol

Same issue for this, refer to TagNoteMapTest.java for the comments on test method naming. For stuff that throws exception, the format should be ..._throwsXXXException().

Is this needed?

Should not have a newline here

Should probably change this to tagSet.

should probably requireAllNonNull here.

Also, is there a need for this method to be public? It seems to be only used here

This doesn't seem to be used, is it in a later commit?

Also, should requireAllNonNull here

Should do this todo, if not the method name becomes confusing.


     * @param countryNotes The set of countries, each containing their notes and associated tags.


     * @param clients The list of clients, each containing their notes and associated tags.


     * Initialises the TagNoteMap from a list of clients.


     * Initialises the TagNoteMap from a list of countries.

Should untagged tags be added to the note?

agree with rayson, also maybe you can have a static final tag object already created in the Tag class, then your ParserUtil can just find Tag.UNTAGGED

Change this to a todo pls, if not we'll forget to remove it

remnants of debugging?

Done

Removed the other duplicate call

Would suggest adding a requireNonNull / assert != null here just in case. Also, what happens in execute if list.size() == 0?

Actually, looking at this, I would suggest implementing a compound predicate instead of having a list. So maybe something like Predicate&gtClient> combinedSuggestionTypePredicate = (client) -> suggestionTypeList.stream().map(suggestionType -> suggestionType.getSuggestionPredicate()).reduce(true, (x, y) -> x.test(client) && y.test(client));

^I didn't test this, but I think it should be correct

Should have an equals and hashcode method, so as to standardize with other predicates, and also enforce the contract between equals and hashcode. Since this class doesn't have any vars, we can just return a constant int for hashcode, and have equals return true as long as other class is instanceof this one

Maybe can just put the assert false and return null in the default block? I think it would make it cleaner

Is this method needed? Is it possible to change other parts of the code so we use the withTimezone(String timezone) method instead?

shld add new line before this to standardize

Too many new lines here

Can add one more assert for just "client" without the space? Just in case.

Same for client note test below

extra new line here

Can rename this to clientCommandType? and the country one to countryCommandType?

rename this to clientNoteCommandType?

Small issue, but the number of equals on both sides aren't balanced

what is this supposed to log? I can't really tell from the code itself, maybe make it explicit with a comment?

why got copyright one lmao

also, should add a todo to change this

Each note should display on a separate line, if not long/many notes will be hard to read

If this path is not supposed to be reached, should just throw an exception here, logging it as info doesn't really make sense. You could probably log the stacktrace though

I like the variables at the top, makes it easy to see, should probably standardize for the whole CSS (can do in a separate issue)

For the scrollbar I think we shouldn't hide it actually, and I feel that the border-radius are a bit too much, maybe can reduce, plus one of the boxes (the one that shows the command messages) isn't rounded, while the rest are

For all the changes in this file, should probably standardize to no space before />, since thats the format of all the fxml files

Also, this help icon should be added to the top context menu (can do in a later issue)

??? why is there this assertNotEquals here lolol

are hamcrest and assertj used? Also, do we need to define JUnit as testCompile? (since we already defined it in our testImplementation/testRuntimeOnly)If we need to, should probably use the jUnitVersion variable instead of a string

fx:id here is empty?

The indentation here is a bit confusing, I think this and StackPane above should be indented 2 more spaces?

I think the indentation and line breaks in this file are off. Can consider taking out the <children\ cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> tag and leaving it as


&gt;StackPane>

    <Label...>

&gt;StackPane>

so that clutter is reduced. </children>

this comment seems to be half-written lol

This variable doesn't seemed to be used

I think a clearer and cleaner implementation of this would be .collect(Collectors.joining()).replace("[", "").replace("]", ""); instead of the reduce

"standardise" should be "standardised"

Where is this view variable used ah

Cuz right now its just being set to WidgetModelManager but on the next line you return a new WidgetModelManager?

Can change this to offset or offsetValue?

why was this newline added lmao

extra newline

Should requireNonNull for country

Actually, do we need this ? extends Note? Would using List&gtNote> be better?

probably can remove this newline


 * A high-level class responsible for mapping ISO3166 countries to their respective country notes.

Actually I would suggest we move isValidCountryCode method to Country class, then this class will be solely in charge of the relationship between Country and CountryNote (SRP), and the classname can be changed to CountryNoteManager I guess

should we put an assert false here?

Should requireNonNull countryNote

Should add simple javadoc for getTags()

Small issue, this should be changed to getCountryNotes

Random "The" here

this sentence is half-complete, I think can just remove the "between"

This png file doesn't seem to have been generated, not too sure why, can you try editing this a bit and pushing again?

extra newline

should have a [else]

Need to update javadoc for this method to match the method behavior

This variable isn't being used

Yeah its cuz the parsing of a date string always needs to have exception thrown

I'm not sure if and how the LocalDate parser does its parsing though, so I would prefer to be safer by mandating the regex check. For example, it might parse 20/19/020 as a correct date and not throw any errors. Apparently using the ResolverStyle.STRICT is supposed to prevent this kind of mis-parsing, but I think the regex would be more defensive coding-like

Done

My bad, fixed it

LGTM

Fixed by #121 #142 #144

Fixed by #120

Duplicate of #92

Duplicate of #90

Removed from plans

Quite a few TODOs and stray comments. I think a follow-up issue can be created to cleanup the todos and stray comments.

Just wondering, what is the main purpose of having TagNoteMap class? Is it so that it would be easier to query for notes based on a given set of Tags? Because it seems like additional work to "sync" tags with notes and it might be quite error-prone if the syncing is not done right. Any thoughts @qwoprocks ?

@raysonkoh actually the implementation @rtshkmr did was a bit off from what I had in mind, the tagnotemap is actually supposed to be the one being passed down from logic manager to the parser to create the tags, so there would no need to do the syncing stuff. @rtshkmr isit alright if i just push to this PR and implement that?

1. Cannot uniquely identify `clients` by their name at the moment.

Possible fix: store the client as a string containing "&gtclient name> &gtclient email>", as we can use isSameClient method of Client to match the clients and notes.

Is the testing for ContractExpiryField class supposed to be done in another PR?

Ah right I forgot lmao I'll add it in now

Do change the USERGUIDE_URL in HelpWindow.java as well!

Switch to use logger

Switch to use logger, same for other 2 instances below

Switch to use logger

Remove

"Clears the item list"?

Would it be better to default quantity to 0 and description/location to none if user doesn't key them in? Currently they act as compulsory fields.

Javadocs

Extra lines

change address-book

Javadocs

change comment title

person -> item

Should these be locationIds and recipeIds?

Should these method names be getLocationIds and getRecipeIds?

use this format instead, replace with the fields we have

plural forms

extra lines

address book -> item list?

Javadocs

Make this comment appropriate pls 😃

Javadocs

the right side has less equal signs 😦

change address book to item list or something similar

same for this segment

change logger message

itemToAdd might be better

extra lines

item -> item and location

person -> item

extra lines

ItemList->RecipeList

item list file path

of recipes

recipe list file path

will fail checkstyle

item -> recipe

checkstyle

can consider shorter prefix

for clarity can change to "Recipe ID is out of range"

should this be {@code Item}?

catch specific exception

add comment above this line specifying that this is for the delr command

conform -> conform to

extra lines

this constructor might be misleading, would it be better to modify the existing one?

for instance


if (!isDeleted) {

    idCounter++;

}

in the existing constructor might make it usable as an equivalent to this one

remove or change to logger statement

Name typo (?), img not updated

[stephentan]

change names in [ ]s to be consistent styling

img not updated

address book -> item/recipe

these steps as well

persons -> items/recipes

actual pictures pls 😃

should this be 3a and 4a?

recipe

standardise with README, use InvInator.jar or change README to inventoryinator.jar

add line back

via the issue tracker of this repository, with link to it

keep names consistent - full name or given name

rephrase to "what is going on under the hood"

should this be "deli stone" for the moment?

delr -n &gtname> -i &gtindex>?

should locations be included as well?

del -> deli

same for this line

delete -> deli/delr

mark as TODO for easier search

optionally provide a short intro on how we structured our personas (explain that our app will help transition the before scenario to the after scenario, etc.)

include option to use


java -jar InvInator.java

contacts -> items

mark as TODO

should we change to deli and delr for now?

should we split del -> deli + delr?

should we split del -> deli + delr here?

i think we should specify that they need to overwrite multiple files, since our storage for each class is in separate files

change titles for each of these files

Should this use the NOT_FOUND message instead? User does not need to know our implementation


itemList.removeIf(x -> !x.getName().equals(productName) || x.isDeleted());

in line 43 looks like it already ensures the item won't be deleted

Suggest to change phrasing to something like

"soft deletes recipes that contain deleted item as product or ingredient"

DeleteRecipeCommand -> DeleteItemCommand

use proper punctuation please

and all recipes associated with the item

please space the methods in this file

spacing

remove this line

@code item

spacing

proper punctuation please

spacing

use block comment

fix spacing in this file

spacing

space out these tests

re-add spaces in this file

fix spacing

spacing

more clear explanation needed

spacing

should these be containsMultipleWordsIgnoreCase?

remove line

is it possible to test results of command? eg. if no such item exists, or check that the item being shown is indeed the right item

import from the file with existing modelstub

deceptive naming

try to remove if not too necessary, is an unusual class to have

use isEmpty

Might be better to not have "will you like to add some?" if there's no direct button to do so

use isEmpty

should this file be added?

Just "No items match the search string." should suffice here

One or more... will suffice

perhaps just "None" is better?

change these tests to using wrong prefix

can remove the old tests once replaced

remove, same for the rest of the printlns in this file

change other list as well

should this be unhidden? same for recipe variant as well

should recipes be reset as well? or is it automatically reset since all items are removed

is now supported as addq, should update this?

will this ever be supported?

same for this

space equally as the above lines

spacing after ,

remove extra line

add test to edit tags

add test for this

standardise to without the "inator", same for rest of instances

Replaced by the ItemParserUtil and RecipeParserUtil

Will be added when future tests require it, currently the item list is needed to reset the item's recipelist so some tests don't contaminate it and affect future tests.

The constructor takes Set in at the moment, might look into this in future

Done in https://github.com/AY2021S1-CS2103T-F13-1/tp/pull/17

Done in https://github.com/AY2021S1-CS2103T-F13-1/tp/pull/16

Issue #30 opened as per review.

resolved by #31

Pushed to future PRs:

LocationList current defaults to Optional.empty, to be fixed and tested.
RecipeParserUtilTest incomplete, does not test for ingredient-related parsing.

Can now be closed, so closing the tutorial PRs.

Opened #73 regarding above comment

needs update of developerguide.md as well

New feature added does not correspond to the feature you were assigned. Possible typo?

Examples provided not changed to match the changed feature.

User command should be just "list" instead of "list 2" to fit the explanation fo the command. Possible typo?

Maybe changing it to "displays all your assignments and lessons for the next 2 weeks" would be more succinct?

How about "displays all your lessons and assignments for the next 2 weeks (including the current week)"?

Looks good!

@printinghelloworld sounds good 😃

Looks good 😃 A minor nitpick is that you may want to consider removing point number 3 ("ASM retrieves lesson data from NUSMods API") as according to the textbook, use cases only describe the externally visible behavior, not internal details, of a system.

Similar to the above comment, maybe it would be better to change the phrasing to describe how the ASM displays the lessons from the newly imported timetable

Maybe including the time the assignment is due in the deadline would be better?

E.g: n/Lab report 3 d/23/04/2020 1230 mod/CS2100

Since we have some optional fields as well, maybe it would be clearer to the user if we changed the description given in AB3 to match our project?

I was suggesting to keep the Tip section and change the description to "You can use the remind tag to set reminders for the assignment you want to add instead of using the remind command after adding the assignment" or something along those lines.

Currently, module code can accept the same string format address in AB3. Perhaps consider changing it the VALIDATION_REGEX to match the format of module codes as well?

Testing of new ModuleCode field may be more accurate if the input was changed to match the module code format.

INVALID_ADDRESS_DESC should be INVALID_MODULE_CODE_DESC for consistency 😃

Similar to the above comment, VALID_ADDRESS_AMY should be VALID_MODULE_CODE_AMY.

Similar to VALID_ADDRESS_AMY comment.

Name of method still refers to address instead of moduleCode. Possible typo?

Could consider changing the test cases to test for valid module codes 😃

According to the 2103T textbook, the suggested guideline for code quality is to break-line after the bracket instead of in the middle of an instantiation.

E.g:

JsonAdaptedPerson person = new JsonAdaptedPerson(

VALID_NAME, VALID_PHONE, VALID_EMAIL, null, VALID_TAGS);

The comment describing the test still refers to address field instead of module code field.

Similar to other comments, the comment describing the test still contains address.

Comments still refer to address. But it is just a minor nitpick 😃

Similar to other comments 😃

This line can be removed 😃

Comment still refers to address instead of module code

Maybe could do more testing to ensure that the regex works as it's supposed to? You can consider testing for modules codes with no alphabets at the start ("1010S"), modules with no numbers ("GER"), modules that begin with more than 3 alphabets ("ABCD1000") etc

Comment still refers to address field.

Similar to other comments relating to address comments 😃

The comment describing the email test is not deleted.

The comment for this test still contains 'email'

yup

This test case seems to still have references to email.

Comment still references email.

Comments for this field use 'persons' instead of 'assignments'. Be sure to check the comments as well 😃

Similar to the other comment, the comments for the field use 'persons' instead of 'assignments'

Similar to the other comment, the comments for the method use 'persons' instead of 'assignments'. Same for the equals method below this method 😃

Similar to the other comments, the comments use 'persons' instead of 'assignments'

Similar to the other comment, the comments for the method and the string parameter at line 9 use 'persons' instead of 'assignments'.

Similar to the other comments, the comments use 'persons' instead of 'assignments'.

Similar to the other comments, the comments use 'persons' instead of 'assignments'

Nice test cases 😃 You may want to consider leaving a space between some parts of the code to make it more readable (e.g leaving a space between lines 79 and 80 and leaving another space between lines 81 and 82)

Similar to the previous comment on improving readability 😃

Similar to the other comments, the comments use 'persons' instead of 'assignments'

According to the CS2103T textbook, the convention for the indentation for wrapped lines should be 8 spaces.

Following the CS2103T convention, you may want to consider changing the indentation to match the one in red 😃

You may want to consider leaving a blank line between some lines to improve readability and code quality (E.g leaving a space between lines 82-83 and lines 84-84). You can refer to the screenshot of the CS2103T coding conventions below 😃

Similar to the comment above on readability 😃 You may want to consider applying the same thing to the other test cases in this class

JavaDocs should be @moduleCode instead of @address 😃

JavaDocs should be @ModuleCode instead of @Address

Since assignment starts with a vowel, it should be "an assignment" instead of "a assignment" 😃 The same typo can be found throughout the project. You can consider using the "find in path" feature in IntelliJ to help you find them (Edit -> Find -> Find in Path)

This test case should be removed 😃

May want to consider adding a link back to the main point which is that ProductiveNUS is supposed to help NUS Computing students resolve the problem so that it is clear what the aim is 😃

I also think it may be better to use more passive language? So instead of 'You often...' it may be better to use 'You may often...'. What do you think?

Looks good! A suggestion could be to bold/box certain words to make the aim more obvious.

The test cases look good! Minor nitpick, the comments next to the valid test cases do not match what is being tested. Also, if the lesson names do not accept numerals in the name, you may want to consider changing the validation regex to only accept alphabets 😃

Nice test case 😃

okie

Naming the deadline field time may be more appropriate for the Lesson class as it doesn't really make sense for a Lesson to have a deadline.

Personally, I feel that using 'schedule' is a little vague. Maybe you could consider changing it to 'schedule manager' or 'schedule book'? What do you think?

Message for duplicate assignment still refers to address book.

According to the CS2103T code convention, boolean variables should be named to sound like booleans (e.g isRemindTypo/containsTypo instead of remindTypo).

I think can just use the hashcode method you created in Lesson.java as given the way you implemented it seems similar to how AB3 implemented it for Person, I think lessons.hashCode() should be fine.

According to the CS2103T coding standards/conventions, we should try to avoid deeply nested methods. Maybe you could consider removing the else block and extracting the "happy path" to prevent the method from becoming too deeply nested. Another suggestion is adding an empty line in between lines of code to improve readability. You could consider applying the SLAP framework as well 😃

I'm not very sure what "Lists the tasks within the next index number of weeks" means. Maybe consider changing the explanation to what is stated in the User Guide?

Nice! You could consider abstracting out the implementation as a private method as the execute(Model model) method is a little long now and according to the CS2103T conventions on code quality, we should try to avoid too long methods 😃

According to the CS2103T textbook, under code quality, we should strive to extract the "happy path" out. You could consider changing the code to extract the "happy path" 😄

e.g:

if (!isNotListAll) {

return new ListCommand(Index,fromZeroBased(0));

}

try {

....

}

According to the CS2103T coding conventions, we should delete code that we do not need 😃 Are you planning to use the commented out code at a later date?

JavaDocs still refer to assignments instead of lessons

Similar to the comment above regarding the JavaDocs 😃

Similar to the comment above regarding the JavaDocs

String still refers to Assignment instead of task 😃

JavaDocs still refer to assignment instead of Task

Similar to the above comment regarding the JavaDocs.

JavaDocs still refer to assignments instead of tasks

JavaDocs still refer to Assignment instead of Lesson

Similar to the comment above regarding JavaDocs

JavaDocs still refer to Assignment instead of Task

Similar to the above comment regarding JavaDocs

Good job 😃 You may want to consider abstracting lines 125 to 135 into another method as this method is quite deeply nested. Remember to SLAP hard 😄

👍

Good job 😃 You may want to consider extracting this part into another method as the CS2103T textbook suggests that we should SLAP our code to improve code quality.

JavaDocs for ScheduleCommand refers to RemindCommand instead of ScheduleCommand.

Good job 😃 A suggestion you may want to consider is to name the boolean variable "can" to something more descriptive and meaningful, as currently "can" doesn't really describe what the boolean is checking for. If you do change the name of the variable, remember to adhere to the CS2103T conventions and ensure that it sounds like a boolean value (i.e isPossibleTime, canSchedule etc)

According to CS2103T conventions, boolean methods and variablels should be named to sound like a boolean (i.e haveOverlap, isOverlappingTime etc)

JavaDocs refer to AddCommand instead of ScheduleCommand.

Is this constructor used for testing?

If this constructor is used for testing, it may be better to create a ScheduleStub class in the test package for testing 😃 But this is a minor issue that can be done when you do UnitTesting.

The JavaDocs for the constructor should be phrased as "Constructs a ...". But this is a minor detail that can be fixed in v1.4 so don't worry about it for now bah 😃

oh okie okie

What's this System.out.println used for? Just curious 😄

JavaDocs conventions for CS2103T is for JavaDocs to phrase JavaDocs in such a way: "Constructs...", "Retrieves....", as opposed to "Construct..." or "Retrieve..."

Since the undo command currently only works with every command except for find and list, you may want to consider adding that information into the message usage and message undo fail so that the user will know exactly why it fails 😃

According to the CS2103T code quality conventions, it recommends that we extract the "happy path".

Maybe stating the priorities would be clearer for the user to understand?

For example, "Sets, HIGH, MEDIUM or LOW priority for the assignment identified by the index number...."

JavaDocs still refers to the remind command for @param

Assignment variable still refers to remind command instead of priority command

False priority is a little misleading as it makes it sound as if the user used the wrong input format for the Priority command instead of setting no priority to the assignment. You may want to consider changing the phrasing of the JavaDocs for the constructor such that it better reflects what the constructor does 😃

Slight nitpick but since you gave the date format before the time format, you could consider using "... finding of assignments by date and time separately", instead of "... finding of assignments by time and date separately". But it is fine if you leave it as it is too 😃

You could consider changing the word prefixes, as it may not be very clear to the user exactly what we are referring to when we say prefixes. Maybe something like "Multiple assignment fields detected. Finding is done one field at a time." then provide examples of what a field is?

The fetching of keywords for each field appears to have some overlaps. You could consider abstracting the implementation and creating a method called getKeywords(String prefix) to improve the code quality 😃

Should be "Tests that an Assignment..." instead of "Tests that a Assignment...". Possible typo?

Similar to the above comment on the grammatical error.

Likewise 😃

According to the CS2103T coding conventions, boolean methods and boolean variables should be named to sound like a boolean. However, it appears that this method is overriding a method from Predicate, so it should be fine 😃

Nice test cases 😃 A suggestion is inserting white spaces between each test case to improve readability. You may want to consider testing for incorrect date and time as well (i.e 31-02-2020 or 2500) to ensure that the parser works as intended 😃

Similar comment regarding the insertion of white spaces 😃

You may want to consider testing for the other fields as well to ensure that they are working as they are supposed to but this is a minor nitpick 😃

Similar comment regarding the insertion of white spaces 😃

You may consider adding in comments to tell the reader exactly what you are testing for (e.g invalid deadline, invalid date, valid time or invalid module code). Though this is just a minor nitpick 😃

Nice use of white spaces 😃

Though you may want to consider using the white spaces to not just improve readability but to group code with similar logic together (i.e grouping all the nameKeywords, deadlineKeywords... List&gtString> variables together and only inserting the white spaces in between priorityKeywords and findByNames. Likewise for the FindCommand variables and the assertEquals methods).

The description and format does not fit the unprioritize command 😃

JavaDocs still refer to prioritize command

Should be "Creates and returns an Assignment..." instead of "Creates and returns a Assignment.."

JavaDocs still refer to RemindCommand

JavaDocs refer to Remind instead of Done

Commends refer to reminders instead of marking assignments as done

Likewise for this comment 😃

Oops must have forgotten to delete the empty return tag when I created this method. You can just delete the @return tag since the other methods don't seem to have the @return tag 😃

The phrasing sounds a little weird to me, though it could just be me XD The "to import" at the end of the sentence appears a bit redundant as well since at the start of the sentence, you already mentioned that the information will be imported.

Maybe "The user can import information about their lessons into ProductiveNUS using their NUSMods timetable URL" would be more concise?

Looks good 😃

Maybe using "Unmarks the 3rd assignment as done" would be more appropriate since undone is not exactly proper English XD But I think the way it is now is fine too.

Likewise for here 😃

Oh when I googled it, Google said unmark is proper English but okie XD

I agree with Andrea 😃

JavaDocs refer to reminders instead of the suggested schedule 😃

address name should change to module code after merging the PR that changed the address field to module code

Sounds good!

Amended 😃

Since we are probably going to be adding an edit feature in the future we can just leave it in first or add it to v1.2 since the implementation is all done for us already 😄

What do you mean?

At first, I made it a non-abstract class, but then IntelliJ made noise because it extends abstract class Command so i either had to override the execute method in NegataCommand or make NegateCommand abstract. Since I personally felt that overriding the execute method in NegateCommand was a little redundant since the UnremindCommand, UnscheduleCommand and UndoneCommand will override the execute method again, I decided to make the NegateCommand class abstract.

I can change it back to a normal class if you want to though, I shall just override the abstract execute method in NegateCommand if you want to change it to a normal class 😃

Oh yup. Must have missed it out. I shall go change it now

Amended!

LGTM.

Will description 'Tags your assignment with a reminder which adds it to 'Your reminders' section' be clearer?

Noted! I have edited the phrasing. Is the edited version clearer?

I have changed some of these user stories to make it more specific. eg. 'work'

Perhaps refer to DG to see which is better?

Updated accordingly 😄

Looks good! Just a small suggestion, maybe we can standardise the use of capital letters under 'I can' and 'so that I can'. we can either capitalise the first word or not capitalise the first word for both scenarios 😃

Sounds good! Which do you suggest is better? I'm fine with either way 😃

Looks good! Just a small suggestion, maybe we can standardise the use of capital letters under 'I can' and 'so that I can'. we can either capitalise the first word or not capitalise the first word for both scenarios 😃

Sounds good! Which do you suggest is better? I'm fine with either way 😃

I think for now we can not capitalise for both scenarios !

Amended 😃

Should we standardize comments? One possible style:

Separate-line comment with whitespace, singular verb, and uppercase 1st character.


// Parses user input...

Command command = addressBookParser.parseCommand(commandText);

Same-line comment with whitespace, singular verb, and lowercase 1st character.


Command command = addressBookParser.parseCommand(commandText); // parses user input...

We could follow any other style too. Just thought it might be better for everyone to stick to 1 for consistency.

Sure, we can restore this when we complete EditCommand.

Really like the regex here. It is simple and effective.

I know this is a bit late, but do you think we should change AddPersonCommand to AddPatientCommand?

I think our Person refers specifically to Patient since we have the periodOfStay field. If we are adding a Staff class in the future, it may be a little misleading since Staff is a Person too.

What do you think?

Since we are using Patient now, maybe we can rename some of these variables?

Perhaps from MESSAGE_INVALID_PERSON_DISPLAYED_INDEX to MESSAGE_INVALID_PATIENT_DISPLAYED_NAME.

Also, do you think we should change our usage of "person" to "patient"? 🤔

i.e. "The patient name..." instead.

I like the use of guard clauses in this method. Makes the code much cleaner 😀

Great work on writing the unit tests! For v1.1, we might not need it but getting it done earlier is a nice bonus.

Maybe it could be invalidPatientName instead? I know it might be a little troublesome to change all references to Person to Patient. I can help with that if you would like.

For separate-line comments, do you think we should keep the first character in uppercase?

The Java coding standard we are using does not explicitly mention it but seems to follow that. I think comments that start with keywords may not need to be capitalized though (e.g. null).

I think "list of patient/all patients that match the specified criteria" may be clearer?

Great use of Optional here!

Do you think an Enum may be preferable here since there are a limited number of possible values?

Using int is not very scalable. If we have 10 different search conditions, we would need 10 int, and it can be hard to keep track of these variables.

Perhaps we can declare a nested Enum:


private enum SearchCondition {

    SEARCH_BY_NAME.

    SEARCH_BY_TEMPERATURE,

    SEARCH_CONDITION_INVALID; // no condition or multiple conditions given

}

If you would like to use int, maybe it would be better to make them static and change the variable names to indicate they are constants. E.g.


private static final int SEARCH_BY_NAME = 1;

Personally, I think Enum might be neater. 😄

Maybe we can add a space here? "TEMPERATURE RANGE " instead of "TEMPERATURRANGE".

This text will be displayed to the user, and the former may be easier to read?

Maybe one private method for each search condition? That would be great.

I'm not too sure but I think the execution will not reach this return statement? If that is the case, I think we can throw a CommandException instead of returning null? Returning null here may cause a NullPointerException somewhere else.

Perhaps we can rename this method to confirmSearchConditions or determineSearchCriteria? area may not be very clear that we are referring to the search conditions.

JavaDoc comments here are really useful to understand the purpose of the nested class. Great work 👍

@itssodium Could you check whether these changes are correct?

If I am not wrong, the Covigent part is the latest edit. It might have been overwritten by accident.

Would you be able to undo the deletion of this file? DateTimeUtil.java was recently added to manage dates and times.

Perhaps we could name this AddRoomCommand instead?

AddNumberOfRoomsCommand seems a little verbose since the number of rooms is implied, though this is a matter of preference.

If you like AddNumberOfRoomsCommand better, let's keep that.

Similarly, perhaps we could rename the command to addroom.

I think it's great that you refactored the code used for I/O. I/O should be abstracted if possible (SRP) since this class mainly handles the adding of the room.

Maybe we can follow the convention here? For messages, Address Book Level 3 follows this convention: MESSAGE_ERROR or MESSAGE_SUCCESS. We could use MESSAGE_NUMBER_OF_ROOMS_UNDEFINED or something along those lines here for consistency.

Would be good to add a comment here if the -1 means something.

Similarly, we can follow the conventions for messages here.

It is less about whether the user will enter a negative number, and more about how we should secure our application.

Personally, I feel that it is good if we can handle as many exceptional cases (sometimes called edge cases) as possible. Without proper handling, anyone can crash the app simply by entering a negative number. It can be annoying for the user if they accidentally type in a negative number and the app just stops working.

Besides, near the end of the semester, our application will be manually tested for bugs. I am fairly sure the testers will try to use negative numbers as inputs. If they can cause the application to crash, they will flag the problem as a bug and deduct our marks for it. Let's do our best to stop that from happening! 😄

May I ask what is the reason for naming the class RoomBook instead of RoomList or RoomQueue? I feel that Book does not explain what the class does.

Would it not be possible to use an ArrayList&gtRoom>?

I think it is easier to understand if you iterate through all the Room objects in a loop and call an isEmpty() method to determine which Room is empty.

Performance-wise, I understand PriorityQueue may be better but we are sacrificing code clarity for performance.

Shouldn't Room contain an ArrayList&gtTask>?

@itssodium Would you be able to check this?

Do you mean it will be used for allocating the Patient to the Room?

Okay, leave this part to me. I will add in the TaskList.

Would it be possible to use Optional&gtPatient> here? While it is true that the Room can have no Patient, it is best to avoid null.

Great that you have a separate class for storage!

I think that is probably the temporary files used for testing? 🤣 Shall we rename the test files?

Yup, Address Book Level 3 has a convention for the names of test cases. Maybe we can follow that next time?

Ohh okay I follow your train of thoughts now. For adding Patient to Room, I think we should be more explicit? Maybe something like AddPatientToRoom.

I think you can use AddRoom for this.

May I check if URI is used here? I think path is a String and URI may not be needed here?

I think it would be good if you could leave a comment to explain the use of the nr and ro options!

Would it be possible to split this test into smaller units? It is currently longer than 30 lines.

Perhaps this part


        rooms = new PriorityQueue<>();

        for (int i = 0; i < 10; i++) {

            Room room = new Room(i + 1);

            if (i % 2 == 0) {

                room.setOccupied(true);

            }

            rooms.add(room);

            roomsInArray[i] = room;

        }

        roomList = new RoomList(rooms, roomsInArray, 10);

        numberOfRooms = Paths.get("numberOfRooms");

        roomsOccupied = Paths.get("roomsOccupied");

        roomOccupancyStorage = new RoomOccupancyStorage(numberOfRooms, roomsOccupied);

        roomOccupancyStorage.saveNumberOfRooms(roomList, numberOfRooms);

        roomOccupancyStorage.saveOccupiedRooms(roomList, roomsOccupied);

        roomList1 = roomOccupancyStorage.readOnlyRoomOccupancy();

        assertEquals(roomList, roomList1);

can be in a separate test?

I think addRooms here refer to allocating a Patient to a Room? Most likely, this test would be in a separate class so maybe we can remove it first?

Don't worry, I can handle this part. 😄 I will have to integrate the TaskList into Room to get my part working anyway.

I think it would be good to leave an explanation of why numberOfRooms is initialized to -1.

Perhaps the messages here can be moved to another class? Ideally, we can avoid adding constants to this class since the messages are stored in seedu.address.commons.core.Messages instead. Maybe look into putting your messages there too?

I think IntelliJ might have changed this to wildcard imports? Maybe we can revert this?

Do you think we should keep the indentation consistent? For *.fxml files, maybe we can use 2 or 4 spaces (not sure what the original is).

I think it would be patients here. Very minor grammatical issue though 😄

I like how there is an order for the different types of entities (patients followed by rooms followed by miscellaneous). Maybe in the future, we can a header to each entity to further organize the content of our user guide? E.g.


3.1 [Command Format](#31-command-format)<br>

3.2 [Patients](<Section explaining what Patients are>)<br>

     3.2.1 [Add a patient: `addpatient`](#32-add-a-patient-addpatient)<br>

// ...

Do you think we should standardize this? Not sure if it is as important in the JavaDocs because it is understandable, but what about the user guide?

Should we refer to the application as the app, the application, or Covigent?

Thank you for noticing and changing this! 😄

Because isSamePatient(...) uses name, age, and phone number as criteria to detect duplicate Patient in a list, will this not pose a problem when deleting? It is possible to have more than 1 Patient with the same name after all. In that case, only the first matching Patient is deleted.

I think it may be a little strange that the user cannot select which Patient to delete if they share the same name. I am not sure about the optimal way to solve this problem. Would deleting by index be better?

Good job noticing the bug here! 😄

Maybe this can be renamed to indicate that an invalid search criterion has been provided. searchPatient does not really explain which aspect is being tested.

Something like execute_searchPatientInvalidSearchCriteria_throwsCommandException() may be good?

I think it would be good to mention something along the lines of how the command replaces the current number of rooms with the newly specified value. Also, whether the data in the current rooms will be migrated or reset.

We can always improve on the user guide in the future though, so maybe we can KIV? 😄

Since there are multiple files being checked, maybe we can include which data file is not in the correct format in the warning.

The same goes for the other warnings.

Maybe we can keep this statement in a single line such that it looks even neater? It has fewer than 110 characters and can fit in one line!

Perhaps we can remove code that is commented out. If we merge this, we may forget to remove it in the future. Also, commented out code seems like regular comments and may be difficult to locate in a large codebase.

Great work with the hashing!

May I ask why the 31 is needed here?

I think maybe we can make this more general and apply it all the other *List classes (UniquePatientList, RoomList, TaskList). Otherwise, I think the interface may not be needed?

Possibly ReadOnlyList&gtT>? We can do either:

Include all methods such as add, delete, etc. (much more work because we have to rename all methods to share a common name).
Include just the method to obtain a read-only list (easier).

Maybe we can add a TODO here to indicate that in the future, we should set the application default to having a few rooms with patients and tasks?

Although ObservableList and PriorityQueue maintain the same rooms, for safety would it be better to include a comparison for the ObservableList too?

The condition for this is rooms != null && roomList.rooms != null but I think neither the PriorityQueue nor ObservableList can be null because of the default value, right?

In that case, can you not just return false if any of the 2 PriorityQueue and 2 ObservableList are null?

Instead of tracking numOfRooms in a variable, would it be possible to just make use of the size of the ObservableList? Maybe include a method to get size (similar to the other *List classes).

This would reduce the complexity of the class, especially when writing the equals(...) or hashCode() method since there is one fewer variable to manage.

@JsonProperty tells the Jackson ObjectMapper to map the JSON property name to the annotated Java field's name so we end up with this:


"room": {

    "roomNumber": value

    "isOccupied": value

     //...

For consistency with JsonAdaptedPerson, perhaps we can keep it the same as the variable name (i.e. roomNumber and isOccupied)? We would have


public JsonAdaptedRoom(@JsonProperty("roomNumber") int roomNumber,

        @JsonProperty("isOccupied") boolean isOccupied) {

//...

We can add a TODO here since we are not using the Patient and Task in this class yet.

Consistent @JsonProperty here! Variable name should be rooms.

Good job with switching to temp folders! 😊

Maybe we can import java.util.Optional directly?

I think if we are not using this class currently, we can remove it 1st?

I will add this when I pull your changes 👍

Might be good to declare a constant for "-" to indicate what it is doing more clearly!

Might be difficult to switch here since there are multiple conditions.

I think the current structure is not too bad. Maybe we can rename clearRoom to isNewEmptyRoom for clarity? clearRoom sounds like the name of a method hahaha.

Also, I think isCurrentlyOccupied sounds more like a boolean. How about we use that instead of alreadyOccupied?

Instead of ...orElse(null) != null, maybe we can use editRoomDescriptor.getIsOccupied().isPresent()?

Would it be possible to combine case 1 and case 3 since both return Room(updatedRoomNumber)? 🤔

!hasNewPatient could be the condition.

Actually, I'm curious about why clearRoom is needed as a condition.

While not entirely linked to this PR, I think we should modify Room to store an Optional&gtPatient>. Then, we can remove the isOccupied boolean and use Optional&gtPatient>.isPresent() to find out whether a room is occupied.

I understand it may be easier to return an Integer but this method is similar to the parseIndex. We can use the Index class provided in the original codebase and use parseIndex instead.

That was what I did in AddTaskCommandParser 😆

Hmm if we modify RoomList directly from EditRoomCommand, we may be breaking a few abstraction barriers since Command will be interacting with RoomList.

To avoid this problem, we can add a setRoom(Room target, Room editedRoom) method to RoomList. Then, add another setRoom(Room target, Room editedRoom) method to Model (the interface). Finally, In ModelManager, call roomList.setRoom(...).

We can then use the setRoom(...) method by calling model.setRoom(...). So we are restricting the interactions between classes such that Command only interacts with RoomList via Model.

Does DuplicateRoom apply only to identical RoomNumber?

Thanks for adding this TODO! 👍

Wait, I see that setRoom has been done. Good job! In that case, why is the modifiable room list still needed?

Also, perhaps we can rename these methods to hasRoom(...) and setRoom(...) for consistency with Patient?

Okay, I see what you mean. For now, we are treating RoomNumber as an index but in the future we may allow the user to set their own room numbers.

Would it be convenient for you to move the room-related methods to RoomParserUtil?

If not, I could do that later because I intend to make ParserUtil an abstract class.

getRoomList() returns the ObservableList though. Wouldn't it be possible to check if the room is present from there?

I think one reason we would not want to return the RoomList is because it is mutable. That means that if we return RoomList from ModelManager, any other class can modify the content through RoomList (e.g. call roomList.addRooms(...)) instead of through the Model (i.e. call model.addRooms(...)).

getRoomList() returns a read-only list so we can prevent the contents of RoomList from being changed directly. In fact, I think that was the original intention behind the asUnmodifiableObservableList() method.

I think editroom command does not allow task to be edited right?

In that case, maybe we don't need to use editRoomDescriptor.getTaskList()?

Maybe it would be good to remove codes that we commented out? Otherwise, we may completely forget about it.

Perhaps the predicate could take on a more meaningful name. What about filterByRoomNumber or something along those lines?

Good job on reducing the number of ObservableList we need!

If we are changing that, I think we can make the method name clearer too. Maybe getFilterByRoomNumberPredicate()?

Let's look into resolving the TODOs in v1.3?

Just wanna check if stylesheets need to be set to each of the element? If I am not wrong, as long as you set stylesheets to ScrollPane, the rest of the elements should inherit the CSS accordingly?

For multiple non-null args, we can use requireAllNonNull(...) instead to shorten the code!

Maybe can explain why this statement is necessary here?

Great work using a listener to update the UI for Room!

Would it not be possible to use getPatientWithName instead? I feel like that may significantly reduce the amount of code that we need.

Might be good to add a comment there to indicate that it refreshes UI.

I think the patient name is the identifier for a patient right? In that case, wouldn't it better to avoid using the Index class?

Would you like to switch to getRoomList() here? We will eventually remove getModifiableRoomList.

If I am not wrong, the two methods getPatientIndex() and getPatientFromIndex() are used in the EditPatientCommand class, right?

Instead of this


        Index index = model.getPatientIndex(patientToBeEdited);



        if (index.getZeroBased() == 0) {

            throw new CommandException(Messages.MESSAGE_INVALID_PATIENT_NAME_INPUT);

        }



        Patient patientToEdit = model.getPatientFromIndex(Index.fromZeroBased(index.getZeroBased() - 1));

Would it not be cleaner to do this in EditPatientCommand?


        Optional<Patient> optionalPatient  = model.getPatientWithName(patientToBeEdited);



        // Better still, use Patient patientToEdit = optionalPatient.orElseThrow(...). I forgot the syntax hahaha.

        if (!optionalPatient.isPresent()) {

            throw new CommandException(Messages.MESSAGE_INVALID_PATIENT_NAME_INPUT);

        }



        Patient patientToEdit = optionalPatient.get();

That way, we avoid using Index altogether.

Oh yeah, this wouldn't work if you use the unmodifiable version. Feels like using the modifiable version is a hack though hahaha.

Actually, we probably should have another class similar to PatientRecord to interact with RoomList. Add, delete, set are done through PatientRecord right now. I think it's fine for now though. Maybe add a note to move this method to the new class once it is set up.

Maybe we can standardize the casing for file names (i.e. logo.png).

I would like to check if we are changing the colour scheme of the UI. I think #2b5c7b is the one we are using in our mock-up.

Since we are removing the menu, I think you can remove the corresponding CSS too!

Maybe keep the format for the comments consistent.

// Set images ...

Do you think setAccelerator() can be removed too?

If we are removing the menu, I think the exit button will disppear too, right?

Similarly, this might not be needed anymore.

Okay, noted on this. I will make the change. Thanks!

Agreed! Let's remove the additional fields.

Yes, right you are! I will change this.

Interestingly, yyyyMd does not work.

Consider the date "12 Jan 2020", for instance. With yyyyMd, it would be "2020112". But this string is ambiguous. Are we referring to "2 Nov 2020" or "12 Jan 2020"?

If we want to use yyyyMd, we would need a delimiter (e.g. yyyy-M-d). I decided against using the hyphen because it doesn't read as well when it is a date range.

Actually, yeah. It is probably not needed for an MVP.

The rationale behind adding DateTimeCreated is to allow the user to filter tasks with creation date as a criterion. For example, in Slack, users can see when the task is created. It is helpful when the user wants to query what tasks were created yesterday or within the last few days.

Right now, the plan is for the user to click on a Room in order to view all tasks assigned to it. There is no separate tab for the users to manage tasks (we should probably have this to show user which tasks from which rooms are due?). In the future, when we implement reminders or a search for tasks, DateTimeCreated might be more useful.

I think I will remove this from the MVP. Unit testing for this class also requires more work because we would need another layer of abstraction to handle and control the date-time instead of using LocalDateTime.now().

Thoughts on this?

Okay!

Nope, it is in an entirely different file. That said, I wonder if it will be confusing for the user?

No problem!

I think p/ is good 😄 We can try to keep it as short and sweet as possible since that's easier to remember.

Good point. Will use that instead 👍

It is missing the success case actually. Will need to set up a stub to perform the test. Will KIV 1st.

Hmm could you clarify on this? I think most of the other Command classes handle add, delete, and update through Model. The Model is the abstraction.

Good point. We should change the names of the tests here!

Yes, @LeeMingDe mentioned this too!

Hmm... Should it be in alphabetical order? I was thinking maybe it should be sorted by the type. We can have Patient, followed by Room, then Task.


3.2 Patient

    3.2.1 Add Patient

    3.2.2 Delete Patient

      ...

3.3 Room

    3.3.1 Initialize Rooms

      ...

3.4 Task

    3.4.1 Add Task

    3.4.2 Delete Task

The current arrangement is like this: the methods that are common to Patient, Room, and Task are placed into ParserUtil. Task-specific methods such as parseDescription are in TaskParserUtil.

Good observation!

Oh I decided to group the success cases together. Might indeed be neater to space them out.

roomNumber cannot actually be null though, because it is a primitive (i.e. int).

Yup that's true. Good observation here 😄

That said, assertions may not necessarily be enabled, especially when an application goes into production.

The roomNumber &gt 0 check is to prevent the application from crashing if this method somehow gets called when assertions are off.

Yup, I think the app is meant to crash in that case. model.getTaskFromRoomWithTaskIndex(taskIndex, room) should return either an empty Optional or an Optional-wrapped task. It should never be null here.

The app will crash with a NullPointerException if taskToDelete is null either way.

Yup, it will crash the app provided assertions are enabled. If getRoomWithRoomNumber(...) is called with a roomNumber greater than 0, it would be a programming error. Crashing in that case is helpful for debugging.

@itssodium would you like to close this PR? I think we could keep the other one instead?

Good work! We will have to correct the CheckStyle problems in order to merge. Would you be able to change the order of imports?

We have decided to close this issue. Don't worry about creating the pull request from master.

For future pull requests, remember that every new feature should be done in a separate branch!

Task models are added 1st. Will be integrated with Room in v1.2.

While not ideal, I decided to force push to my own repo in order to squash the commits that contained only minor changes for CheckStyle compliance.

I will be more careful when pushing to my repo in the future.

Overall, clean and neat code! Believe you haven't integrated the command into the code yet but seems like good support for your command for now. One thing though, I am not sure why you want to have a DateTimeCreated for task? Anyway, LGTM!

Haha, yeah I set up the PR to update everyone with my progress. The integration is not complete yet. I will request for more reviews when the integration is done.

To fix your addressbook and let it show its contacts, follow these steps:

Go to your data folder

Open up addressbook.json

In the second line, change "persons" to "patients"

I recommend deleting data/addressbook.json if you have not added any custom data. Upon restarting the app, the file should be regenerated.

Additionally, the logic in readAndSaveRoomList unit tests may be difficult to follow without comments. Do you think it would be possible to add


// Save in new file and read back

RoomOccupancyStorage roomOccupancyStorage = new RoomOccupancyStorage(numberOfRooms, roomsOccupied);

// ...

to indicate that you are saving and loading the file for testing?

There is also some code duplication in the readAndSaveRoomList tests, which we can consider refactoring into private methods.

I removed the link to #58 because we haven't actually displayed the Patient and Task details for each room. We can definitely merge 1st though.

Rebased to avoid additional merge commit.

lgtm, good job! However, the pr is super long, would it be better to like split it up in the future? eg. do the tasklist/task class and merge it first. then the addTask command and then merge it?

Totally agree with this. Ideally, I think a PR should not exceed 500 lines. It is difficult to review the PR when it is that long. I originally wanted to split this as well. Will definitely do so in the future! 👍

getRoomWithRoomNumber has been implemented in #115. Can use that for EditRoom too.

I think "the filename of the profile photo should be doc/images/githbub_username_in_lower_case.png" - Week 7 Point 2 in Project

Might wanna consider team/samlsm instead

Missing space before 4a.

Remove extra space

Missing "Use case ends."

Inconsistent comma, (+ EMAIL_DESC_BOB,)

//// student-related tests may work better here instead of Student, since we also have //// moduleClass-related tests

Extra space

See if its possible to trim down this part. I took a couple of tries before I understood what was going on

The {@code ModuleClass} must not exist in the current list

Don't quite understand this. Specifically, don't understand what is a backing list and what is meant by unmodifiable


    /** Returns an unmodifiable view of the filtered 

     * {@code ModuleClass} list.

     */


    // student-related constants


    // moduleClass-related constants

Need full stop for this comment

Comments start with lower letter + no full stops


        // workaround as storage functionality for ModuleClasses has not been implemented

Ok lets retain it in that case

Missing space


            + PREFIX_TELEGRAM + "johnDO3 "

Consider keeping the previous tag set? Because its more of an app to track students rather than keep address contacts.

I think the tagset got overwritten. Saw that you merged the master branch into your branch

Might be good if we remove the telegram prefix, since user has to type @ for email. So we might want to keep the design consistent by making them type @ for telegram handle

An alternative would be to update both the UG and DG to reflect the telegram handle changes.

I personally would go for the former than latter. How about the rest?

Any reasons why "student" was removed?

Extra white space

Any reasons for removing this white space?

Resolved by sticking to using TELEGRAM_PREFIX = "@"

Any reasons for removing this white space?

Resolved by adding back "student" in command


     * @param index Index of the class in the filtered class list to edit.


     * @param editModuleClassDescriptor Details to edit the class with.


        // short circuit if same object


        // instanceof handles nulls


        // state check


     * @throws ParseException If the user input does not conform the expected format.

I think the full stop got removed for some reasons.

My current updated code base has a full stop for this comment


 * Parses input arguments and creates a new FindStudentCommand object.

@throws ParseException If the user input does not conform the expected format.


            || (other instanceof ModuleNameContainsKeywordsPredicate // handles null)

start with lower case, e.g


        // one keyword


     * Returns an {@code EditModuleClassDescriptor} with fields containing {@code moduleClass}'s details.

Can you help center the fencing for the table?

Can you help organise/center the fencing "|" for the userguide table as well? I remembered centering it awhile back during v1.1 but seems like some of the fences got out of position again


Shows a list of all students and all classes in the application.

Might want to consider putting this after DeleteModuleClassCommand.COMMAND_WORD but before LinkCommand.COMMAND_WORD to maintain a fixed action sequence

"3" seems like a magic number across the test script. We might want to consider abstracting it into a variable in a separate PR

I think we should use Color since the naming before the change was Color

I agree with Dexter on this


     * Deletes the given {@code Student} and the {@code Student}'s {@code UUID} in all {@code ModuleClass}es.


     *  Deletes {@code key} from this {@code TutorsPet} and also the {@code UUID} of {@code Student} from all {@code ModuleClass}es.

Just to clarify, the reason why you create a new hashset is because the set returned by getStudentUuids() is immutable?


        // manually remove UUID

Is this change because if a student is deleted, then the associated student in ModuleClass is removed as well?

Extra space

Can we remove this space? Since line 17 and 19 are both messages

Space between line 15 and 16?

The words undone and redone are kinda awkward but I think its okay if we express it in that way, since it still gets the message across in a succinct manner


     * Creates a {@code StateRecords} with the specified {@code currentIndex} and {@code stateRecords}.

Extra space

I agree with Dexter on this. We can probably extract the CRUD operations to Logic instead of clustering everything in AttendanceRecordListTest.java

We can shift the CRUD here out to another class as well

Any reasons for this spacing?

Would recommend putting new back, since we are technically still generating a new Lesson

Nice assert


        Name moduleClassName= targetModuleClass.getName();


            + PREFIX_WEEK + "WEEK_NUMBER (must be a positive integer) "


            + "Note: All indexes must be positive integers.\n"

Swap line 91 and 92 for consistency


assert targetWeek != null;

Maybe keep the original?


            + "by the index number used in the displayed class list "


     * Adds all edited lessons in the target module class to the new module class.

We can consider adding this for AddLessonCommand and DeleteLessonCommand as well

👍🏻

Then we might have to do a full refactor for all occurrences and stick with it? Because from what i remember, many of the shorthand for loops do not have spaces


            + "Existing values will be overwritten by the input values.\n"

            "Note: All indexes must be positive integers.\n"

We can remove "must be a positive integer" from these 3 indexes to keep the formatting consistent with AddAttendanceCommand and DeleteAttendanceCommand

Can we separate the else if to another if guard clause to keep the format consistent?




        String message =

Separate guard clause




        if (!isModuleClassIndexPresent || !isLessonIndexPresent || !isStudentPresent || !isWeekPresent) {




        if (argMultimap.getValue(PREFIX_PARTICIPATION_SCORE).isPresent()) {

Thanks for the catch!

Can we abstract out these values like AddAttendanceCommandTest and DeleteAttendanceCommandTest?

E.g


Index moduleClassIndex = INDEX_FIRST_ITEM;

Index lessonIndex = INDEX_FIRST_ITEM;

Index studentIndex = INDEX_FIRST_ITEM;

Week targetWeek = VALID_WEEK_1;



assertThrows(NullPointerException.class, () -> new DeleteAttendanceCommand(

       null, lessonIndex, studentIndex, targetWeek));

Nice catch!

Can i check why is there a change to getOneBased() ?

Can update the above /s to \

Sry, is there a reason why this is being replaced?

I see!

Should we add in null tests for the other test cases as well?

Would it be good to keep this? Because there might be multiple aspects to a feature


Users should not have to type in attendance-related commands when the student is absent from a lesson.

I'll send in a separate PR to update my pros and cons section as well. Lets follow your style of having the pros and cons as individual pointers rather than paragraphs


            + "Note: All indexes and numbers must be positive integers.\n"

Resolved by removing MODULE_CODE

Resolved by removing [] for all fields within add apart from [tag/TAG]

Resolved by updating line 58 to


e.g. `[tag/TAG]…` can be used as ` ` (i.e. 0 times), `tag/student`, `tag/TA` etc.

Resolved by adding in commit suggestion


**List Students in Class** | `list-students /by n/CLASS_NAME`<br> e.g., `list-students /by n/CS2103T Tutorial T10`

Resolved by changing clear class to "clear-class"

Resolved by changing list students to "list-students", and title to "Listing all students within a class"

Resolved by retaining {:toc}

Resolved by removing redundant add

Resolved by moving ellipsis outside of square brackets

Resolved by removing address field and updating tag prefix from /t to /tag

Ok i won't be touching it in that case

Added the tags, used tag/average and tag/TA candidate to keep formatting consistent

I think it'd be better if the summary comes before the detailed explanation. As a user i wouldn't want to scroll downwards if i just want to reference the commands. What do the rest think?

I thought of that, but the issue is that the formatting will not be standardized across the table and commands. I feel that perhaps its better to caps everything so that we standardize our documentation

Issue is that the formatting will not be standardized across the table and commands. I feel that perhaps its better if we follow the actions used in the command summary?

Changed Command summary to Command list

Resolved by rewording expression to show that Tutor's Pet can return more than one user found

Will keep clear instead of changing to delete

Ok lets keep the previous

Will be keeping line 155 instead

To change to requireAllNonNull(uuid, name, phone, email, tags);

Good catch, thxs, no point editing UUID so no point adding UUID into EditStudentDescriptor.

Resolved by removing setUuid() and getUuid()

Resolved by changing line 93 to UUID updatedUuid = studentToEdit.getUuid();

To add a DEFAULT_UUID in StudentBuilder.java and convert it to a UUID for usage instead of generating a random UUID for testing

Resolved by removing UUID field

Resolved by specifically adding Uuids into TypicalStudents

RIP, forgot to remove sneaky boi

Added the following :

JsonAdaptedStudent.java


        if (uuid == null) {

            throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid"));

        }

JsonAdaptedStudentTest.java


    @Test

    public void toModelType_invalidUuid_throwsIllegalValueException() {

        JsonAdaptedStudent student =

                new JsonAdaptedStudent(null, VALID_NAME, VALID_PHONE, VALID_EMAIL, VALID_TAGS);

        String expectedMessage = String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid");

        assertThrows(IllegalValueException.class, expectedMessage, student::toModelType);

    }

Since UUID is a built-in java class, instead of doing something like throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, Name.class.getSimpleName())); , i opted for throw new IllegalValueException(String.format(MISSING_FIELD_MESSAGE_FORMAT, "uuid"));

Possible, but the json "studentIds" in the json file will be changed to "studentUuids". Which one do you guys prefer?

I initially added a class entry, but then eventually removed them as I wanted to isolate the test cases better (Since this json file is more to test for invalidstudent rather than invalidclass.) Any thoughts?

Currently since we are using UUID.randomUUID(), the edge case that could potentially happen is a null UUID rather than that of a UUID that is not specified properly, unless the user decides to edit the uuid in the json file to a smaller uuid string. Hence i decided to only test for toModelType_nullStudentIds_throwsIllegalValueException()

Any thoughts on this?

Was thinking that a guard clause would be sufficient (Since its likely the case that a uuid is either well defined (by using Java's UUID.randomUUID(), or null))

Any thoughts on whether a try catch is needed here? Will include one if needed

Thats a good idea. I'll pull information from ALICE directly and remove the TODO comment

Resolved by keeping status quo for invalidClassTutorsPet.json (ie no changes)

Resolved by adopting suggested change

Resolved by pulling information from ALICE directly and removing TODO comment

Resolved by refactoring all occurrences of studentIds to studentUuids, including the studentIds field in model ModuleClass.java

Resolved by abstracting code inside toModelType() into two smaller methods.

Resolved by adding try catch block

Resolved by introducing checks for invalid UUIDs

Yes, it applies across all UUIDs so long they are not invalid

An example of an invalid UUID is "fffa3023-7d89-426b-ba01-" // No uuid values after dash

In contrast, a valid uuid is "fffa3023-7d89-426b-ba01-d45eaa" // Missing values after d45eaa are padded with zeros

Resolved by using existing information from ObservableList&gtStudents> in tutorsPet

Will change it to One or more of the given indexes are invalid.

Could be a typo on the user's part. Would recommend keeping the Use case resumes at step 1.

Added moduleClassIndex parameter into getAddLessonCommand

Abstracted to ModuleClassUtil

Added guard clause to check if attendance exist in the first place, and added negative test case to check for error message throwing for this scenario

Changed to following AddAttendanceCommand format and throw MESSAGE_CONSTRAINT instead

Added assertion for both DeleteAttendanceCommand and AddAttendanceCommand

Inserted assertion

Simplified for both AddAttendanceCommand and DeleteAttendanceCommand

Created ModuleClassModificationUtil and LessonModificationUtil classes to address this

Lets do it in a separate PR.

createModifiedModuleClassWithModifiedLesson is used in AttendanceCommands. It is specifically used as a bridge to modify a targeted module class after CRUD has been done on attendance and stored inside a lesson. createModifiedModuleClassWithEditedLesson specifically performs CRUD on the lesson itself

We can use manualReplaceLessonToModuleClass from ModuleClassUtil for now since there are no test cases for those methods which you've mentioned yet

I'd like to check with you guys on how we should go about handling this block.

Problem : removeAttendance(...) throws CommandException when it is unable to find an attendance to delete. This works for individual attendances, but if we doing a cascading delete (ie removing all occurrences of the student), then we would want to return the attendanceRecord even if no student can be deleted.

Solution 1 (Currently implemented) : Do a try and catch to overwrite the CommandException

Solution 2 : Remove the removeAttendance(...) abstraction and use the underlying code in removeAttendance(...) in this method. But this will violate SRP.

Solution 3 : Propagate the CommandException upwards to LessonUtil and ModuleClassUtil and eventually UniqueModuleClassList. But downside is that you eventually have to handle it with try catch.

To go with solution 1

Completed

This seems to be missing the saving of UUIDs to local storage, is that planned for a separate PR?

To implement saving of UUIDs to local storage

Mostly looks good to me, just need some minor changes.

Could you also add a test case to ensure that EditStudentDescriptor does not change the UUID of a student?

I think this part of EditStudentDescripterTest.java factors in that UUID isn't changed? Otherwise it will return false if the UUID changes


public class EditStudentDescriptorTest {



    @Test

    public void equals() {

        // same values -> returns true

        EditStudentDescriptor descriptorWithSameValues = new EditStudentCommand.EditStudentDescriptor(DESC_AMY);

        assertTrue(DESC_AMY.equals(descriptorWithSameValues))

Not sure if we need to get approval before we merge this in since we are trying to use a new module?

Module has been removed (Last checked 26/09/2020)

Looks great! But like what Dexter said, I am not sure whether we need to get permission first.

Module has been removed

@ypinhsuan can yours work? my one works fine

Decided not to implement UUID equality check as it may risk introducing a lot of bugs into the code

Not required.

Use \ , update test cases to use PREFIX variables instead of hardcoding commands (e.g "\c")

I like your specifying: STUDENT_INDEX and CLASS_INDEX

Perhaps it is clearer to define 'index' as follows?


*`STUDENT_INDEX` refers to the index number shown in the displayed student list.

*`CLASS_INDEX` refers to the index number shown in the displayed class list.

Minor grammar issue, should it be is and not are?


* 5a. At least one of the given indexes is invalid.

Same as issue above.


* 5a. At least one of the given indexes is invalid.

Should we include test cases for UUID? Such as public void toModelType_nullUuid_throwsIllegalValueException().

Apologies, mistake on my part for not typing correctly. Should be


    public void toModelType_nullUuid_throwsIllegalValueException() {

Otherwise, looks good to merge.

Should the tense follow the DeleteStudentCommand class instead?


    public static final String MESSAGE_DELETE_MODULE_CLASS_SUCCESS = "Deleted Class: %1$s";

Nice abstraction.

Should the filtered list be specified?


     * Updates {@code model}'s {@code filteredStudents} list to show only the student at the given {@code targetIndex} in the

Same as above.


     * Updates {@code model}'s {@code filteredModuleClasses} list to show only the ModuleClass at the given {@code targetIndex} in the

Same as above.


     * Updates {@code model}'s {@code filteredModuleClasses} list to show no module classes.

Perhaps naming studentIds as studentUuids would make the code clearer?

Should there be at least one class entry here? We can follow invalidClassTutorsPet.json, which has a valid student entry.

Should you insert a INVALID_STUDENT_IDS list (and test case) also? Perhaps you can use a string that has less than 4 hyphens

Nice handling of null UUIDs. However, would it be better if a try-catch block is used on UUID.fromString(uuid) instead? Then, any kinds of wrong UUIDs can be handled.

I think you missed out on this:


    public static final String MESSAGE_DUPLICATE_MODULE_CLASS = "Class list contains duplicate class(es).";

I think you missed out on the TODO comment. Perhaps instead of importing these STUDENT_UUID_X in test cases, we can call ALICE.getUuid() from TypicalStudent class instead.

Should this for loop be placed in another method for proper SRP? The for loop above that iterates through jsonAdaptedStudent can be similarly placed in another method. Then, this toModelType() method will call these two for loop methods.

To add on, according to Java's UUID API, UUID.fromString() throws IllegalArgumentException. Perhaps you can use this alongside with your null guard clause.

I notice this try-catch block appearing in other parts of the PR. I think the proper way would be to write our own interface for UUID. But, for now, I think it is not needed.

Should you indent this line?


<fx:root minHeight="600" minWidth="740" onCloseRequest="#handleExit" title="Tutor's Pet" type="javafx.stage.Stage"

         xmlns="http://javafx.com/javafx/11.0.1" xmlns:fx="http://javafx.com/fxml/1">

I noticed that these 3 lines of code are repeated in above test cases. Perhaps can consider abstracting these out into a private method?

Should this be:


        ModuleClass specifiedClass = showStudentsInModuleClassAtIndex(expectedModel, INDEX_FIRST_ITEM);

Should this be in the same 'format' as above?


        assertCommandSuccess(new ClearModuleClassCommand(),

                model, ClearModuleClassCommand.MESSAGE_SUCCESS, expectedModel);

Would it be better to test against the moduleClasses directly? Since we are adding (and removing) them along with their studentUuids.


        assertFalse(modelManager.hasModuleClass(CS2103T_TUTORIAL));

        assertFalse(modelManager.hasModuleClass(CS2100_LAB));

Similar to above.


        assertFalse(tutorsPet.hasModuleClass(CS2103T_TUTORIAL));

        assertFalse(tutorsPet.hasModuleClass(CS2100_LAB));

Perhaps you can convert the for loop in ViewHistoryCommand into a method residing in StringUtil class.

This is to avoid the explicit construction of expectedMessage. For completeness, the new StringUtil method also needs to be unit tested.

Should you move the 1 and 50 to static constants?

Perhaps naming the variables as they are is good enough?


    public static final String VALID_TIME_1400 = "14:00";

    public static final String VALID_TIME_1600 = "16:00";

    public static final Day VALID_DAY_WED = Day.WEDNESDAY;

    public static final int VALID_NUMBER_OF_OCCURRENCES = 7;

    public static final String VALID_VENUE = "COM1-B111";

Should you also test the edge cases of 0, 50, and 51?

Perhaps you can consider renaming WED_2_TO_4 to LESSON_WED_2_TO_4, so as to avoid confusing this constant as a time object.

Just noticed, not sure if 'integer' is considered a technical term.

Nice check.

I don't really quite get the purpose of the cache.

Understood the cache. Logger lgtm.

I think should be Class'.


    public static final String MISSING_FIELD_MESSAGE_FORMAT = "Class' %s field is missing!";

    public static final String MESSAGE_INVALID_STUDENTS_IN_LESSON = "Invalid student(s) found in lesson(s).";

    public static final String INVALID_FIELD_MESSAGE_FORMAT = "Class' %s field is invalid!";


            if (!studentUuids.contains(studentUuid)) {

                throw new IllegalValueException(MESSAGE_INVALID_STUDENTS_IN_LESSON);

Just throwing out this alternative: perhaps placing the Week object here would be better instead of in the JsonAdaptedAttendanceRecord class. So instead of having a List&gtJsonAdaptedAttendanceRecordList> attribute, there can be a Map&gtWeek, JsonAdaptedAttendanceRecord>. Jackson supports Json serialisation of Maps: https://www.baeldung.com/jackson-map.

Purpose is for symmetry between the Model classes. And I think it may help in reducing lines of code and tests.

I think this current implementation is also suitable for purposes of this project.


  "_comment" : "StudentAttendance contains an invalid student attendance score",


  "_comment" : "StudentAttendance contains duplicate student UUID",


  "_comment" : "Records contains a null student UUID",


  "_comment" : "Records contains a null entry",


  "_comment" : "Record list contains duplicate AttendaceRecord",


  "_comment" : "null recordList",


  "_comment" : "recordList is empty",

Would this be better?


            + "lesson on a specified week.\n"

            + "Note: All indexes and numbers must be positive integers.\n"

            + "Parameters: "

            + PREFIX_CLASS_INDEX + "CLASS_INDEX "

            + PREFIX_LESSON_INDEX + "LESSON_INDEX "

            + PREFIX_STUDENT_INDEX + "STUDENT_INDEX "

            + PREFIX_WEEK + "WEEK_NUMBER";

Should this be moduleClassIndex?

Perhaps you can consider writing a test case for finding attendance in a filtered list?

Should you insert an assertion for lessonToEditIndex?


        assert targetModuleClass != null;

        assert lessonToEditIndex != null;

        assert lessonToUpdate != null;

Perhaps an assertion can be included here to check that the size of updatedAttendanceRecord has decreased by 1.

I think this can be simplified to


        Lesson modifiedLesson = new LessonBuilder(lesson)

                .withAttendanceRecordList(new AttendanceRecordList(updatedAttendanceRecords)).build();

I am wondering if these lines, along with the private methods declared below, can be abstracted into a class that deals with the manipulation of the Lesson and Attendance related classes. These lines of code are repeated in other commands and in test cases as well.

Should this be a requireAllNonNull check, since it is a public method now?


        requireAllNonNull(targetLesson, targetStudent, targetWeek, attendanceToAdd);

Same as above. I notice that this occurs in the other refactored classes as well.

Should you shorten the name of this method as well as the other refactored methods? Perhaps use addAttendanceToLesson?

Should the methods from LessonModificationUtil and ModuleClassModificationUtil be used here instead? Perhaps we can do it after unit tests for these 2 classes are completed.


     * @see tutorspet.model.Model#getTutorsPet()


 * Represents a storage for {@link tutorspet.model.UserPrefs}.


     * Saves the given {@link tutorspet.model.ReadOnlyUserPrefs} to the storage.


         * @see tutorspet.logic.Logic#execute(String)


     * @see tutorspet.logic.Logic#execute(String)

I think it would be great to include a javadoc comment here to summarize the purpose of this class.

Same as the above comment on javadocs.

Should you put these 2 variables as static constants or under a @BeforeEach method? They are used commonly in the test cases.

Same static constant abstraction comment as above.

Should you abstract these 2 lines out into a private method? These 2 lines are repeated in the add and edit methods.

For statements such as these, would it be better to put the String.format method on the next line?


        assertParseFailure(parser, " "

                + PREFIX_LESSON_INDEX + "1" + " "

                + PREFIX_STUDENT_INDEX + "1" + " "

                + PREFIX_WEEK + "1", 

                String.format(MESSAGE_INVALID_COMMAND_FORMAT, MESSAGE_USAGE));

Same as above.

Similar to the above comment, would it be better to format the statement as follows?


    private static final String INPUT_PREAMBLE = " "

            + PREFIX_CLASS_INDEX + VALID_MODULE_CLASS_INDEX_ONE.getOneBased() + " "

            + PREFIX_LESSON_INDEX + VALID_LESSON_INDEX_TWO.getOneBased();

Nice catch!

I think it will be good to add a unit test that tests this method directly.

Should this be h3 size instead?


### Display Statistics Feature

I think this should be labelled 1 throughout?


1. `Logic` uses the `TutorsPetParser` class to parse the user command.

1. A new instance of a `StatisticsCommand` object would be created by the `StatisticsCommandParser` and returns to

 `TutorsPetParser`.

1. `TutorsPetParser` encapsulates the `StatisticsCommand` object as a `Command` object which is executed by

 the `LogicManager`.

1. The command execution calls static methods from the `ModuleClassUtil` and `LessonUtil` classes.

1. The result of the command execution is encapsulated as a `CommandResult` object which is passed back to the `Ui`.


* **Alternative 2 (current choice):** Extract the methods out to another class


    * Pros: Does not violate the law of demeter. Increases cohesion and thus increases maintainability.


The Undo/Redo mechanism is designed around maintaining a history of `TutorsPet` states, and restoring a particular state when the user triggers an undo or redo command.

Perhaps consider reordering these statements or shifting the TutorsPetState diagram lower? So as to establish a clearer link to the diagram.

Should 'Alternative' be renamed as 'Choices'?


  * Pros: Will use less memory (e.g. for `delete`, just save the student being deleted).

Would it be better to shift this diagram to around line 278? The explanation is rather dense there.

Sure!

Should this method return a double instead to avoid rounding off errors?


            totalParticipationScore += getParticipationScoreFromLesson(lesson, targetStudent);

Same consideration as above, to change the return type to a double.

Would it be better to indicate 'weeks'? So index 4 will be name of the lesson and index 5 will be the string of weeks not attended.


            + "%4$s, Weeks: %5$s";

Would it be better to return List&gtInteger> or int[] here, where each element of the list/array is the week number the student is absent? This will reduce the responsibility of this method and make testing easier. The method to convert this list to a string can be shifted to StatisticsCommand and be made private.

Same consideration as above to change the return type to a List or Array.

Can!

Should you move this into a private method in this class?

I think you missed out on the casting. Might have to tweak some of the test cases also.


        return (double) totalScore / numOfWeeksParticipated;


For example:

Yup

@junlong4321 yup, that is right.

@dextertanyj agreed, will remove a student not in any classes.

Agreed. I was not so sure what exactly is to go into the Logic and Model components. That's why I switched to int.

Have included similar tests for JsonAdaptedModuleClassTest and JsonAdaptedStudentTest.

I think I will stick with the space, because it follows the comma then space convention.

For example: new A(a, b, c). So it feels more natural to have the space after colon.

Agreed. But I cannot do it for AddLessonCommand as there is no list to 'compare' to.

Changed to spaces before and after colons

I think I will leave it like that for now, because I want to show Attendance. Will clarify with Prof Damith or Clarence.

Yup, we should standardize comments. I think we can just follow the style you suggested. Everyone okay? @raymondge @itssodium @chiamyunqing

is it be better to use comment.trim().isEmpty() instead of comparing it to null?

i think you can use the TODO function so its easier to check what you have to do next time

eg.

//TODO: your todo item here

i'm not very sure, does the java doc require the parameter and the return value? eg.


/**

 * Returns true if a given string is a valid age.

 *

 * @param test....

 * @return boolean.....

**/

same for the java docs here!

okay can!

is it better if we do addpatient instead of addPatient? just asking out of curiousity, no need to change if you think its fine

i think this should be addPatient instead of add?

do you think we should add in details like the temp must be 1dp or that the age must be in the range from 0-120?

hmm, why do you need this variable? Essentially, the numofRoomsInString is equal to Integer.toString(numOfRooms). so maybe you can just use that instead of declaring another variable?

so for this, you can just use Integer.toString(numOfRooms)

maybe you want to change the name to SearchPatientDescriptor? can rightclick, refactor -> rename

not sure if this will fail the checkstyle because of multiple empty lines

i think you can change the Person's to Patient's

i think that this method might be a bit long, so maybe you want to extract out some lines of code into a new method? Its just a suggestion, it's fine without it also

I think the one that was removed is correct? Might need to check

is there a reason behind initializing the numerOfRooms to -1?

perhaps it might be good to catch the exception for negative integers inputted by the user?

Sorry, I don't really understand the need for a PriorityQueue in this class, can you explain the rationale for ti?

can i know whats the purpose of this constructor? because its empty but yet it takes in an integer parameter

i think i saw the method below this comment in the RoomBook class, so there might not be a need for this method here?

same as the previous comment, this method might be a duplicate?

since you are creating a new room every time the user adds a room, i think the previous data in the room might all be wiped?

this might be a duplicate method too?

it's only null for now right?

i think this might override the data of the previous rooms too?

i think you might want to change your naming for the priority queue and not use rooms? i got quite confused trying to read it

since you are only counting the number of occupied rooms directly, will there be a problem with this? eg.

i have 3 rooms

room 1
room 2
room 3

So lets say room 1 and room 3 are occupied. so numberOfRoomsOccupied = 2 correct? But next time if you load the RoomBook, it will give me room 1 and room 2 occupied since the numberOfRoomsOccupied is 2?

is the name of the file lol?

this indentation might be abit off?

let's work with the naming together for the test cases next time!

is there a purpose for this method?

i think you can delete this method if it is not in use

hmm, i dont really think there is a need to test if the priority queues are equal? or if you want to test, you can just do


int[] array1 = roombook1.toArray();

int[] array2 = roombook2.toArray();

Arrays.equal(array1, array2);

i think better naming of the paths would be good? it's a little bit hard to understand/remember what the constructor of RoomOccupancyStorage is supposed to take in

by accident? maybe a slip of the finger?

hmm, but i think you can just chain the methods together? like .getRoomBook().getRooms() etc

hmm, i thought that this field not supposed to be here anymore?

Hopefully we won't get merge conflict for this when we merge our UI hahaha

thanks for helping me to change what i have missed!

same here, thanks for catching this

should we make it such that there cannot be patient with the same name?

Is there a typo here? don't think we have UndoCommand and RedoCommand right? hahha

if this part is not needed, then will it be better to just delete it?

i think you can delete this line and subsequently, the convertPriorityQueue method

can delete the method below. i dont think it's in use anymore. i only created it to bypass the need for an observablelist

i'm not sure why it cannot be yyyyMd, is there a difference?

i think he used it because it allows easier tracking of the tasks due date using DateTime instead of a string

Very good use of ObservableList, this will help immensely in the integration into the UI!

i think this should be null dateTime instead of email?

i think this prefix is already used for periodOfStay in PatientCliSyntax.java, will it be affected?

thanks for cleaning up my unused method from before! 👍

i think its fine. It makes me wonder if I should convert my editroom prefixes to p/ instead of pn/ for patient name. hahahah

Yup, adhering to abstraction principle is good, however i feel it might not be worth it to extract only 2 lines of code into a new method. maybe what wl can do is to perhaps give a name to the variable to make it clearer.

eg. String[] stringNames = searchPatientDescriptor.getStringName().split("\\s+"));.

same here, abstraction principle is good, however, it might not be worth it to extract them out into a new method

yup! is there a reason why you are checking if the search result has only has one value? I'm referencing to the (patientNameList.size() == 1) cuz your getListOutput(list) method will just print out everything

hmm, just curious ah, why dont want just String stringName = argMultimap.getPreamble().trim().toLowerCase()? so eg. if you have searchpatient alex n/something, your stringName will be alex.

Also, what is the substring(2) for ah? i think for very long but i still cant figure it out

can consider Returns instead of Return? also, do we have to leave a line after line 70? i kind of remembered that it is in the coding convention but im not sure.

might be good to have a java docs header before this!

maybe you can use model.getUnmodifiableRoomList() here? model.getUnmodifidableRoomList() returns an ObservableList&gtRoom> too. i discussed with yh last time about how the command class shouldnt be interacting directly with the room class but rather through the model class

i changed the checkIfRoomPresent() method to a static method because of the reason below. ideally, i feel that checkIfRoomPresent() should be in RoomList.java class. what do you think?

should there be an empty line before this line of code in the java docs?

should there be an empty line before this? also, there are some extra white spaces in line 23

same for the empty line before this

ah, i see i see, sorry!! hahaha

do you want to consider removing this comment? is it needed?

would be good to have a class header for java docs!

you can consider renaming your test method to toModelType_returnsOccupiedRoom_success() here.

same here for the naming

i think you can consider looking at the JsonAdaptedPersonTest class for an example of what to test!

hmm, why do you need this method? is it to get access to the ObservableList? If you are not planning to modify the elements in the ObservableList but planning to "look at" the elements in it, you can consider the asUnmodifiableObservableList() method in this class at line 84

do you want to consider moving these few lines of code into the map function from line 55? you can just write a one liner val = trimmedDueAt and i think it should do the trick?

can consider val = trimmedDueAt so that any whitespaces are removed

let us know if you need help with writing json test cases! Although Json is unfamiliar to me too, i'm sure we can work something out

consider adding a java docs header here

consider adding a java docs header here. Looks good to me for the testcases!

you might want to standardize the naming of methods, so maybe this method can be toModelType_sameModelType_success(). same for subsequent methods below toModelType_sameModelType_throwsException(), toModelType_sameModelType_failure()

remember to remove println statment here. you can consider adding a //TODO before using println statements, so you won't forget to remove them

can remove instead of commenting if this is not going to be used in the future

hmm for this right, why not just throw an exception in the method? why do you need to have a try-catch block to catch the exception and throw the same exception? eg. public void setTask(Task target, Task editedTask) throws TaskNotFoundException {

Edit: Nevermind, i understood, its because its a void method

would it be better to name the test parseCommand_editTask_failure() or parseCommand_editTask_throwExceptions() instead? Same for the tests at the bottom too!

actually, do you need to wrap this part in a else statement?

need fullstop here for java docs?

full stop here too?

i think you can unwrap from the else statement here too?

i think you should be asserting if the roomNumber is null? Because if the roomNumber is &gt0 then it should be the user fault and not the system fault no?

same here for what yq and i mentioned previously

makes sense, let me change it later

oh ya, i forgot. ill change it later

okay, let me change it now and update the pr

yup, i think i missed out on that, thanks!

i thought its already editpatient?

okay can can

whoops, let me rectify that

the - means that its deleted

all the red lines are deleted lines!

okay, will change it, thanks!

okay can, I will change it

i think instead of arraylist, it might be better to use ObservableList directly. ObservableList is what is passed into ListView (UI component) and allows the UI to be updated whenever there is a change in ObservableList.

okayy, ill change that real quick

yup, i will change the indentation. good catch

alright man, i have reverted all the wildcards imports! thanks for pointing it out

the "-" is to remove the patient from the room! so eg. editroom 1 pn/-, it will remove the patient from room 1

okayy, i will change it later! thanks for pointing it out

yup, good idea

i'm not sure how to use a switch here because the if conditions are all different, maybe you want to give me some suggestions?

yup sure! i will change it

cuz i feel like its not really an index, so grouping it under the index class seems wrong

okay, let me try it out

yes

because i have to check if the room is present in the ObservableList. There is no way to access the RoomList other than through the ModelManager.java. i don't think its suitable to have a method in ModelManager.java to check if the room exists and to return that room

sure, i can move the room related methods to RoomParserUtil

I'm allowing the users to set the room number already, so index might not be that great...

yup, i just changed it!

i initially used hasRoom() and setRoom(). i forgot why i didnt use hasRoom() but i didnt use setRoom() because roomList class already has setRooms(), i feel that it will be quite confusing to have 2 methods named so closely to each other but does totally different things

Yup, my test cases were failing, so I added a toString() to check. I thought about removing it, but I figured you might need it. Feel free to delete later. Don't think it matters

Hmm, now thinking about it, it does seem like bad design. I'll change this later and update this pr. I will probably use the observablelist.stream().anyMatch to replace this (so it will stay in EditRoomCommand.java but won't have a method) . Do you think its a good idea?

This is one of the dilemma I'm facing. Whether to have a static method in RoomList.java or have a method in EditRoomCommand.java (that is out of place). I think i will adopt the same method of just using the observablelist.stream.anyMatch() method and not create a new method. How does it sound?

Since i have to change other parts, I think i will just update it in case I forget about it in the future

thats true, let me shift the code there then

i will shift this method to the model manager also

okay sure!

HAHAHAH, i wrote it that way so the method name not so long. will change it later!

good catch on the ambiguity! i will make it clearer!

there should only be one patient in a single room though. also, it doesnt move the patient, you have to clear the patient from the room first. maybe for v1.3, i can implement the auto remove and move feature

yup, good catch. i removed it

because the original css also have scrollPane in it, so i specified the css

okay

because initially it was just internalList.add(sth) and it wasnt updating the UI unless i change it to setAll

not really, kinda forced to do it this way unless i dont use Index class for this method

if i dont use Index class right, then i'll be using integer instead. cuz if i use roomlist.getObservableList.indexOf(getPatientWithName("some name here"), it will return -1 if the patient is not found. but Index class doesnt accept negative integer, so it will throw out an exception

okay sure

so its kinda like a comparison of using int vs using Index, because either way, i need the position of the patient from the list

mayeb i will use this.roomList.getRoom..., because getRoomList returns the unmodifiable version

yup. i dont really feel its a hack tho, cuz the ModelManager is supposed to interact with the roomlist directly. We should make it so that other classes cannot interact with the roomlist directly and remove the getModifiableRoomList though

yup, wasnt really thinking sorz >&gt

that is true, we can look into this for next week

oki, i will do that next time HAHHAHA, didnt see

You can take a look at the RoomListPanel.java for references. I suspect the problem arose because you are calling patientDetailsPanel = new PatientDetailsPanel(patientToDisplay) and patientDetailsPanelPlaceholder.getChildren().add(patientDetailsPanel.getRoot()) repeatedly. Perhaps you can move both these LOC from the handleMouseClick and updateDetailsIfChanged method into the constructor for PatientListPanel.java

Actually does the user need to list all modules first before adding a new one ah?

Maybe an empty list shouldn't affect the addition of a new module? If not a user can never add his first mod since the list will be empty then LOL


 * Duplicates are not allowed (by .isSameModule comparison)

Should we update the default pathname to gradpad.json or something along those lines?

I think we can update the javadocs for these changed methods 😁


     * Adds a new {@code Module} to the {@code GradPad} that we are building.

This test fails cos 2 Modules shouldn't be equal if they have different module codes. Perhaps we can remove the module code change


        Module editedAlice = new ModuleBuilder(ALICE).withTags(VALID_TAG_CORE)

I think we need to update TypicalModules.ALICE cos the tests can't build since ALICE is an invalid module. It'll probably be good to rename it too LOL cos alice is still a person's name

Maybe we can rename the dummy path since we're no longer building addressbook 😁 Same goes for the change on line 46 below


        userPrefs.setGradPadFilePath(Paths.get("gradpad/file/path"));

Same as prev comment

Maybe we can remove the regex split? It doesn't do anything since module codes never have spaces in them. Maybe we can just create an array with the module code in it as a single string:


        String[] keywords = { CS2103T.getModuleCode().moduleCode };

This is exactly the same as the CS2103T in the prev line HAHAHA so it'll always return true LOL

In this test, we are seeing if modules with the same module code and MCs, but different tags, will be considered the "same" by GradPad, so maybe we can just change the tag:


        Module editedModule = new ModuleBuilder(CS2103T).withTags(VALID_TAG_NON_CORE)

Nit: I think we need to update the javadocs for this method

Let's change these example tags HAHA altho I wish modules could give me friends and money...


    public static final String MESSAGE_DUPLICATE_MODULE = "This module already exists in the grad pad";

Perhaps we can rename the variable editModuleDescriptor here and also the references in the few lines below it.


        EditModuleDescriptor editModuleDescriptor = new EditModuleDescriptor();


    public static final String MESSAGE_DUPLICATE_MODULE = "This module already exists in the grad pad.";


    /**

     * Stores the details to edit the module with. Each non-empty field value will replace the

     * corresponding field value of the module.

     */


    /**

     * Creates and returns a {@code Module} with the details of {@code moduleToEdit}

     * edited with {@code editModuleDescriptor}.

     */

I think we need to update the javadocs here 😁


 * Deletes a Module identified using its displayed index from the grad pad.

Perhaps we can use camelCase for the property names? JSON properties are basically hashmap keys; so just like how we wouldn't use multiple words (with spaces) in a key or variable name (altho JS/JSON allows), maybe we can use moduleCode or module_code instead?


     * Constructs a {@code JsonSerializablegradPad} with the given modules.

Not a suggestion/request for change, but I was just wondering why the original code does this redundant check here when it could just call gradPad's setModules fxn, which already uses UniqueModuleList to ensure all modules are unique.

I just put this comment here first in case we want to improve code quality next time.


List<Modules> gradPadModules = modules.stream().map(JsonAdaptedModule::toModelType).collect(Collectors.toList());

try {

    gradpad.setModules(gradPadModules);

} catch (DuplicateModuleException ex) {

    throw new IllegalValueException(MESSAGE_DUPLICATE_MODULE);

}

I think we need to rename the file also 😁

I think this test assertion is the same as the one a few lines above 😁

Since it's supposed to include other valid values, perhaps we can do:


        userInput = targetIndex.getOneBased() + CODE_DESC_CS2103T +  INVALID_CREDITS_DESC + CREDITS_DESC_CS3216;

        descriptor = new EditModuleDescriptorBuilder().withModuleCode(VALID_CODE_CS2103T).withModularCredits(VALID_CREDITS_CS3216).build();

Nit: the test is perfectly fine but maybe we can replace the dummy keywords with module names

The lastModule is already CS3216 right HAHA so we don't need to "edit" it with the same code and credits again


        Module editedModule = moduleInList

                .withTags(VALID_TAG_CORE).build();

😁 I think the re-naming of the variable was missed out


 * A utility class to help with building EditModuleDescriptor objects.


     * Parses the {@code tags} into a {@code Set<Tag>} and set it to the {@code EditModuleDescriptor}

nit: typo

This module is valid HAHA

It's why the test for invalid module in JsonSerializableGradPadTest isn't passing

Nit: grammar 😆


ease your module planning process. A module searching platform is also included in GradPad, providing easy


class to create a corresponding `AddCommand`.

I think the method call wasn't specified; is it supposed to be AddCommandParser.parse()?

We need to change deletePerson(1) in line 51 😁


deactivate GradPadParser

typo? hehe

Maybe we can rename the return variable as a or smth? I only named it e in my diagram cos it stands for EditCommand 😁


Format: `add c/ {module code} cr/ {modular credits}`

What does the timestamp in the status bar refer to ah?

Grammar nit: Not really sure how to tweak it but "successful find" sounds a bit weeeird? 😁

Maybe one way could be "...in GradPad to successfully show the found module."?

Yeah okay that sounds good 👍

Let's update the javadocs too 😁

Should we add "matches part of any word in ModuleCode" too? Since now we support it

Do you think we should remove "multiple words" ah? I feel like it might be an irrelevant equivalence class now that we use a .contains() check

Removing it will also match the new test cases below since we're removing the old tests involving multiple words

Is there a typo for help modules? LOL actually can't tell cos this is still a correct invalid command HAHA


3.  GradPad displays the deleted module onto the `Command Line Display`


**Use case: UC05 Edit a Module in `Current Modules`**

I think we also need an extension to cover the case when invalid fields are given e.g. credit/5 instead of cr/5

Actually it's not just the required module list righttt cos that's only like ~10 mods out of all 150 CS mods that they can search for


1. User requests to search for a module in the CS curriculum.

Same comment as previous 😁

Perhaps it might be better to list this out separately? Maybe below this sentence we can put:

The following module details will be displayed:

module code
title
etc

I think square brackets are only for optional arguments? Actually are we following the original UG syntax format ahhh? I'm not too sure

Suggestion: Should we explain that we allow users to edit multiple fields in the same command?

Minor minor code nit: perhaps this could be joined into one if statement instead of nesting so readers can easily tell what this block does (i.e. check if user is disconfirming)


        boolean isDisconfirmation = stalledCommand instanceof Command && !commandText.equalsIgnoreCase("yes");

        if (isDisconfirmation) {

You mentioned that you were concerned about messiness earlier but I think this implementation is fine actually! 😀

But if we want to, we can abstract this out into a stallComponent fxn that handles the stalling. It might take in a Command, do the necessary stalling/operations, then return the CommandResult. This will make things more future-proof cos we don't know how many future commands need confirmation, and we don't wanna keep stuffing everything into execute


        if (command instanceof ClearCommand || command instanceof DeleteCommand) {

                return stallCommand(command); // returns the CommandResult

        }

These two lines need to be swapped 😁 cos we don't want to stall the command before checking that it's valid, which only happens when we call getModuleToDelete.

Right now if we type in an invalid delete e.g. "delete 100000", the command is still stalled and GradPad will wait for a confirmation. When a user then corrects himself and types "delete 1", GradPad will say "command aborted" instead of executing the corrected command

Really really small nit: I think this method can remain as private since only handleStall should use it HAHA Actually how come it's changed from private -> public since the last review ah?

Since we have so many messages here, perhaps we can shift this into a class on its own e.g. RequiredCommandMessages to avoid bloating the RequiredCommand class. We can then do static imports as needed

This code seems to be repeated in a few compareX fxn so it might be good to abstract it out into a getModulesToAdd(&gtrequiredModuleList>) fxn or something along those lines that takes in a List and returns the string modulesToAdd

Maybe we can name this isFoundationCleared to make it more boolean-like? Same applies for the other compareX functions

Perhaps we can use a java StringBuilder here since we're iteratively doing string concatenations (line 91). Otherwise we'll be doing O(n) operations per iteration and this fxn will run in O(n^2) 😁

Maybe it'll be better if we handle the exceptions in this command instead of propagating it cos that would mean we need to change the execute contract (as has been done). But in doing so, we are breaking the interface segregation principle since ALL other commands are also now bound to a contract that isn't applicable to them.

(cont. from prev comment)

So maybe what we can is to wrap these error-throwing calls in a try-catch block and handle exceptions here instead. After all, clients expect this execute method to give them a result (success or failure message), and not an exception.


try {

        setFoundationStorage(FOUNDATION_PATH);

        setITprofStorage(ITPROF_PATH);

        setMathAndScienceStorage(MATHANDSCI_PATH);

        setScienceStorage(SCIENCE_PATH);

        setInternshipStorage(INTERNSHIP_PATH);

} catch (IOException | DataConversionException e) {

        // from the error msg you wrote in MainWindow hehe

        return new CommandResult("File not found :(");

}

Maybe we can declare the pathstring as a class-level constant instead to make it obvious where the filepath is stored when we need to change it next time 😄

Same as RequiredCommand, perhaps we can wrap this in a try-catch and handle the exception here rather than propagating it and binding all other commands to a new contract

Same as previous comment in RequiredCommand, we can use a StringBuilder instead so that this fxn can run in O(n) instead of O(n^2)

Maybe we can initialize this to an empty Optional instead of leaving it as null? I think it's a bit weird that the field can either be null, empty Optional, or filled Optional when the purpose of Optionals is to abstract away nulls anyway HAHA

But this one is really a minor suggestion 😁

Perhaps we can consider using this instead:


        assertTrue(actual.isEmpty());

As mentioned in the java API, it's generally not recommended to do equality checks for Optionals cos they produce unpredictable results 😁 Same applies for the other tests below and also ScienceCommandTest

Shouldn't areModulesCleared become true when we find out that the user has taken a science module?

Likewise if areModulesCleared is true then shouldn't we be showing MESSAGE_SUCCESS_SCIENCE instead since the user has cleared this basket HAHA

How come taking a single internship module means that areModulesCleared is false ahh? I tot it should only be false if total MCs &gt 12 since we need >= 12 in order to clear the internship basket >&gt

I FEEL LIKE IM MISSING SOMETHING OBVIOUS LOL SO PLS FORGIVE ME IF I AM HAHA IM DAMN CONFUSED

Actually how come we need the areModulesClearedflag instead of using an if-else statement ahhh?

Just to clarify, is this code saying: if a module is taken, then add its MCs to modularScore. If it's not, add the module title/mc to the result to display instead.

PAISEH I'm very confused here ><


            if (doesModuleAlreadyExist(module, currentModules)) {

                int modularCredits = Integer.parseInt(module.getModularCredits().toString());

                modularScore += modularCredits;

            } else { 

                String moduleToAdd = module.getModuleCode() + " (" + module.getModularCredits() + " MCs)";

                leftOverInternship.append("\n").append(moduleToAdd);

            }

I think we might not need to catch, reconstruct, and re-throw the same exception? HAHA We can just remove the try-catch block 😁

I think there's no IllegalArgumentException to catch here LOL StringUtil.ignoreCase and SearchCommand's constructor both don't throw ittt

Just interesting side note (no need to change anything!):

JUnit tests automatically fail if any exception is thrown so we don't need to be concerned with catching exceptions and failing the test ourselves 😄

Oooh okay! My bad hehe I didn't realised that checkArgument in StringUtil.ignoreCase() throws an undeclared IllegalArgumentException (since its a runtime error)

No need to change, this is great 😄

Updated these 2 badges so that when you click on them, they take you to our repo's CI and codecov pages respectively:

Let me know if this regex is fine cos I'm not too sure what kind of module codes we support

I left the contents unchanged for now as I only needed the tags as defaults

I added module field templates here and left the rest of the templates alone. We can remove at the end if nobody else needs them

I only added CS2103T and CS3216 as new modules in this class and left everything else alone first. Likewise, if nobody else needs them, we can remove them at the end

Oh yeah you're right. In that case, I'll let filterModuleSummaries take in a bunch of keywords to filter against. We can then define the keywords in a hardcoded constant depending on the list of required modules.

Ui looks great but I think the website says it has to be the ard the same size as the original. Right now it's too big:

Feel free to resize, update the PR, and merge in your own time! 💯

I think this issue is too big and general? Maybe each person can create an issue specific to their work e.g. my issue should be "Add feature list and command summary to user guide" since I'm doing first page of our google docs

@yan-soon typos have been fixed; thanks so much for catching them!

Update: As per @shaokiat suggestion, tweaked filterModuleSummaries method in DataFetcherManager class to accept multiple keywords to filter against. For now, I put some sample keywords in a constant MODULE_FILTER_KEYWORDS in the same class. We can change it when we work on required modules?

Tertiary student instead of Tertiary students

expenses/incomes instead of expenses/income

Manage instead of manage


* Responsibilities: Scheduling and Tracking, User Interface




/**

 * Parses input arguments and creates a new AddExpenseCommand object.

 */

Add the full stop. The corresponding comment in AddIncomeCommandParser should have a full stop as well.


        assertParseFailure(parser, "1" + INVALID_TITLE_DESC, Title.MESSAGE_CONSTRAINTS); // invalid title


     * @throws ParseException If the user input does not conform to the expected format.

Either


        INCOMES,

        EXPENSES,


        INCOME,

        EXPENSE,


    public void parseCommand_unrecognizedInputWhenOverviewTab_throwsParseException() {

Also in other similar places.

Is it possible to not hard-code the value 7? Same as in ListIncomeCommandTest and ListTransactionCommandTest


        assertEquals(model.getFilteredExpenseList().size(), getTypicalExpenses().size());

This together with an additional import statement:


import static ay2021s1_cs2103_w16_3.finesse.testutil.TypicalTransactions.getTypicalExpenses;


        // ensures that outOfBoundIndex is still within bounds of finance tracker list of expenses


        // ensures that outOfBoundIndex is still within bounds of finance tracker list of incomes

Line 73


// ensures that outOfBoundIndex is still within bounds of finance tracker list of transactions


    - Add a class to store frequent expenses/incomes (such frequent expenses/incomes will be in a separate list)


    - In Analytics, make use of `YearMonth` instead of `LocalDate`


 - Investigate feasibility of UI testing. If not viable, then remove it from the testing suite.


        Expense editedBubbleTea = new TransactionBuilder(BUBBLE_TEA)


    public static final Expense TUITION_FEES_2 = new TransactionBuilder().withTitle("Tuition Fees")


    public static final Income TEACHING_ASSISTANT_2 = new TransactionBuilder().withTitle("Teaching Assistant")


    public static final Expense BUBBLE_TEA_2 = new TransactionBuilder().withTitle(VALID_TITLE_BUBBLE_TEA)


    public static final Income INTERNSHIP_2 = new TransactionBuilder().withTitle(VALID_TITLE_INTERNSHIP)


            assert (transactionToEdit instanceof Income);

            return new Income(updatedTitle, updatedAmount, updatedDate, updatedCategories);

Since the previous assertion was removed, maybe an assertion here might be necessary? Same for similar occurrences.


            assertTrue(transactionToEdit instanceof Income);

            editedTransaction = editedTransactionBuilder.buildIncome();


            assertTrue(lastTransaction instanceof Income);

            editedTransaction = editedTransactionBuilder.buildIncome();


            assertTrue(transactionInFilteredList instanceof Income);

            editedTransaction = editedTransactionBuilder.buildIncome();


* On app launch: Initializing the components in the correct sequence, and connecting them to each other.


    public static final String COMMAND_WORD = "convert-frequent-expense";


    public static final String COMMAND_WORD = "delete-frequent-expense";


 * Deletes a frequent expense identified using its displayed index from the finance tracker.

Remove unnecessary newlines.


    public static final String COMMAND_WORD = "edit-frequent-expense";

Should FrequentExpense be a subtype of Expense? Consider the fact that they appear in different lists, and are treated very differently. Moreover a method to convert a FrequentExpense to an Expense is implemented .Also note that FrequentExpense should not have a Date field, since its date is undefined. Only the Expense that it converts to should have a date.


public class FrequentExpenseList implements Iterable<FrequentExpense> {

This follows from the class TransactionList and the deprecated ExpenseList and IncomeList. This will account for the method iterator in line 82.

With reference to the comment on line 11 in FrequenceExpense, date should not be present.


     * Constructs a {@code JsonAdaptedFrequentExpense} with the given frequent expense details.


     * @throws IllegalValueException if there were any data constraints violated in the adapted frequent expense.

These lines are repeated in lines 106-107.

Remove extra newline.

This class seems debatable. Note that TransactionBuilder was used to cover both Expense and Income. Should the same be done here? i.e. FrequentTransactionBuilder to cover FrequentExpense and the upcoming FrequentIncome.

Similar to the issue in FrequentExpenseBuilder, should a class TypicalFrequentTransactions cover for both FrequentExpense and FrequentIncome?


     * Returns an unmodifiable view of the frequent expense list.

Same with similar Javadocs in this class.

This method seems to be taken from getFilteredExpenseList and getFilteredIncomeList, which are found to be buggy. Please modify it to be an ordinary getter.


    /** Returns an unmodifiable view of the filtered frequent expense list. */


            "The transaction index provided is invalid.";

Is it possible to just have equals since these two methods are exactly the same?

Also, for the sake of consistency, use:


getTitle().equals(otherFrequentExpense.getTitle())

Similar for other places.

Unnecessary use of super.

This method is repeated in AddExpenseCommandParser and AddIncomeCommandParser. Perhaps in a future PR this method could be placed somewhere else, then imported into classes that require it?

Remove unnecessary newlines.

These Index objects are repeated from those above. I would suggest reusing those above rather than create multiple repeats of the exact same object. Perhaps maybe rename the three indexes above to something more general, like INDEX_FIRST and so on.

A more appropriate name should be used.


     * Converts this Jackson-friendly adapted frequent expense object into the model's {@code FrequentExpense} object.


        FrequentExpense validFrequentExpense = new FrequentTransactionBuilder().buildFrequentExpense();

Undescriptive variable name

There is a similar method in TypicalTransactions. Moreover, the FinanceTracker object returned by this method has no transactions while the other one in TypicalTransactions has no frequent expenses. Consider putting these two classes together so that getTypicalFinanceTracker will return a FinanceTracker object that has at least one item in each of its lists.

.iml files should not be committed. Also, there should not be an .iml file here in the first place, unless you did something you were not supposed to do.


        return internalFrequentIncomeList.iterator();


        FinanceTracker sampleFt = new FinanceTracker();


            @JsonProperty("categories") List<JsonAdaptedCategory> categories) {

For some reason checkstyle accepts indentation level 8, though according to the textbook in this case it should be indentation level 12.


            @JsonProperty("categories") List<JsonAdaptedCategory> categories) {


            @JsonProperty("incomes") List<JsonAdaptedIncome> incomes,

            @JsonProperty("frequentExpenses") List<JsonAdaptedFrequentExpense>

Follow this indentation for the lines below as well.


     * Returns an unmodifiable view of the list of {@code FrequentExpense} backed by the internal frequent expense list of


     * Returns an unmodifiable view of the list of {@code FrequentIncome} backed by the internal frequent income list of

Remove unused field.

Shouldn't this test mirror FrequentExpenseListTest? There are less tests here than in FrequentExpenseListTest.


    public <T extends Transaction> FrequentTransactionBuilder(FrequentTransaction<T> frequentTransactionToCopy) {

        title = frequentTransactionToCopy.getTitle();

        amount = frequentTransactionToCopy.getAmount();

        categories = new HashSet<>(frequentTransactionToCopy.getCategories());

    }

Glossary terms shall remain unformatted. Edits will be made.

Yes, it will remain unchanged.

Agree. This will be handled in a future PR.

PR has been recorded by the grading script.

ModelManager::filteredTransactions was ideally supposed to contain both expenses and incomes from FinanceTracker::expenses and FinanceTracker::incomes, through the methods FinanceTracker::getExpenseList and FinanceTracker::getExpenseList while completely omitting FinanceTracker::transactions. Thus, ModelManager would have 3 lists while FinanceTracker would have 2.

However, the implementation of the class FilteredList is that one of its fields (source) is an ObservableList object, and constructing a FilteredList as such:


ObservableList<E> observableList = FXCollections.observableArrayList()

FilteredList<E> filteredList = new FilteredList(observableList);

would result in source = observableList.

In essence, a FilteredList object needs to keep track of an ObservableList object.

Thus, filteredTransactions needs to keep track of its own ObservableList object, and cannot track both expenses and incomes together. Therefore, FinanceTracker::transactions cannot be removed, and neither can the class TransactionList.

Possible solutions:

Add a switch statement that refreshes the tab after every command.
Modify CommandResult to indicate any changes.
Make use of listener, somehow.
Add additional getters for the lists or for the transactions based on index.

FinanceTracker::resetData does not account for frequent incomes. This stems from FrequentIncomeList class missing some methods. Reference FrequentExpenseList for these missing methods. From there, FinanceTracker and ModelManager should have similar methods as well.


* Tertiary student


| `* * *`  | user              | set a monthly spending limit    | track how much I have left to spend for the month                      |

Don't commit .iml files.


* **Tools**:

Newline at EOF.

parseEmail should be renamed to parseDate with the corresponding parameter renamed. Same for all other instances.

parseTag should be renamed to parseCategory with the corresponding parameter renamed. Same for all other instances.

parsePhone should be renamed to parseAmount with the corresponding parameter renamed. Same for all other instances.


     * Parses an {@code String amount} into a {@code Amount}.


     * @throws ParseException if the given {@code amount} is invalid.


     * @throws ParseException if the given {@code date} is invalid.


     * Parses a {@code String category} into a {@code Category}.


     * @throws ParseException if the given {@code category} is invalid.


     * Parses {@code Collection<String> categories} into a {@code Set<Category>}.

parseTags should be renamed to parseCategories with the corresponding parameter renamed. Same for all other instances.


The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `TransactionListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class.


<div markdown="span" class="alert alert-info">:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Category` list in the `AddressBook`, which `Transaction` references. This allows `AddressBook` to only require one `Category` object per unique `Category`, instead of each `Transaction` needing their own `Category` object.<br>


ecp -> ec ++: index, editPersonDescriptor

Let's update the diagrams at a later stage.


Simply add the following to [`seedu.address.ui.PersonCard`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-0c6b6abcfac8c205e075294f25e851fe).

Let's revert this change since we will most likely be deleting tutorials eventually.


       Person editedPerson = createEditedPerson(personToEdit, editPersonDescriptor);

Could you import EditCommand.EditTransactionDescriptor instead?


 * Adds an income to the finance tracker.

The command result display is not big enough to display everything, nor can it be scrolled. Instead, the words are just cut off.

Should something else be used instead of menu? Having to click the Menu, then the MenuItem for tabs is very clunky. An alternative is JavaFX TabPane.

I don't think the help menu should be grouped with the other options as the other options are tab headers while the help menu is a menu.

This extra line break can be removed.


     * Opens the analytics window.

Missing full stop.

panelLabel does not seem to correctly reflect the chosen tab.

Note how Income is selected, yet the label displays Expense.

If the JavaFX TabPane were used, I don't think you need to write such hacky code.


     * Creates an {@code ExpensePanel} with the given {@code ObservableList}.

Should this class be dealing with Expense objects instead of Transaction objects?


     * Creates an {@code IncomePanel} with the given {@code ObservableList}.

Should this class be dealing with Income objects instead of Transaction objects?

Any reason why these imports aren't grouped with the others?

Move this import up with the other imports, and leave a line after the last import.

This might be due to the bug found by @zhaojj2209 whereby switching tabs works only for the first time since the application was started.

Unable to reliably replicate this. I'll close this comment for now and keep and eye for this bug occurring in the future.

@siddarth2824 will be addressing this in a separate PR.

See https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/75#discussion_r501141034.

This will be changed in a future PR once the Expense model is more fleshed out.

This will be changed in a future PR once the Income model is more fleshed out.

Add full stops? Same for the other comments.

Possible to add backticks to parts which reference code? i.e. AddCommand


            + ": Deletes the expense identified by the index number used in the displayed expense list.\n"


            + ": Deletes the income identified by the index number used in the displayed income list.\n"


 * Deletes an income identified using its displayed index from the finance tracker.


 * Deletes an expense identified using its displayed index from the finance tracker.

Currently, these specific success messages are being shown. Should these be removed?

This value depends on the number of entries in our test data though. How do you propose we get around this without hard-coding?


    public void execute_showsAllExpenses() {

Sounds weird otherwise. 😕


    public void execute_showAllIncomes() {

Is this line break intended?


    - Edit find commands to be similar to edit commands e.g `find INDEX KEYWORD`

Should the date be set in the CNY period?

Perhaps bullet points detailing the behaviour of the command on each tab could be moved from the format section to the description section? @yongping827 what do you think?

Can getFilteredExpenseList return an ObservableList&gtExpense> instead?

Similarly, can getFilteredIncomeList return an ObservableList&gtIncome> instead?

Can we enforce the subtypes within the list itself?

Use a more descriptive variable name.

Remove extra newline.

This is quite bad design. Perhaps we should just throw an error when executing any of the base commands which should never be executed?

Refer to issue #125.

Is this assertion necessary?

Similarly, is this necessary?


`JsonAdaptedExpense` and `JsonAdaptedIncome` are JSON-friendly adaptations of `Expense` and `Income` respectively.

pitest can be added at a later time when we get around to achieving full coverage.

My bad, removed test.

I thought that the GITHUB_TOKEN secret was being blocked due to this PR being from a fork. Seems to also happen with branches on this repo. 😕

Apparently, GITHUB_TOKEN cannot be used; must be a GitHub user's personal access token.

Setting the baseurl to be the repo name is necessary for GitHub Pages to function.

CI job is able to run now. Tested on a branch of this repo as PRs from forks are unable to access secrets.

See https://github.com/AY2021S1-CS2103T-W16-3/tp/runs/1160121842.

@yongping827 The corresponding comment in AddIncomeCommandParser does not have a full stop, should I still add it?

This was left as such to mirror the corresponding change in #56. Can I confirm this is not intended?

Edit: Never mind, just saw https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/63#discussion_r499263026.

Full stops to be added separately. This is honestly very low priority.

Hmm, I went with ListTransactionCommand as the commands shouldn't have to care about the state of the UI; that's the job of the FinanceTrackerParser.

This comment is here because the contents of this file needs to correspond to the transactions created in TypicalTransactions. For the other test JSON files, they have no such dependency.

I was wondering why IntelliJ was throwing warnings for the pitest task in build.gradle. See https://github.com/szpak/gradle-pitest-plugin#eliminate-warning-in-idea. For documentation purposes only; I agree that this change feels less readable.

Requested for permission to use the external library at nus-cs2103-AY2021S1/forum#253.

LGTM!

While the current deployment process works with personal access tokens, @wltan brought up the point that we should have it work with the repository token GITHUB_TOKEN instead. This is a more ideal solution, especially if Prof Damith were to adopt the use of jekyll-spaceship.

Relative links are currently not working. Trying to find a fix.

PR has been picked up by the grading script.

Closed with #50.

Screenshots

Desktop:

Mobile:

Could you rebase to address merge conflicts before we start reviewing?

Issue seems to be caused by spaces in the file path.

Define the allowed inputs for Title and Category more explicitly in the user guide. The intricacies of the input validation cannot be captured within MESSAGE_CONSTRAINTS without making it unnecessarily verbose which is not user friendly.

See #130.

Can consider renaming function to execute_invalidPersonName... instead of Index since we are editing by name now.

Just a side note, can consider "editPatient" as command word in case we want to have an "editTask" command in future. Up to you! 😃

Good use of Optional here!

Typo @code instead of @cod

I like how you included this test!

Your implementation of editpatient supports editing multiple fields in 1 command. Can consider adding an example of this. E.g. editpatient Alex Yeoh c/Add comment d/20200303-20200315

In the example, should be editpatient not edit haha >&gt

Perhaps you want to consider changing the message to "Search for patients who fulfill the given criteria in Covigent." since the output may be a list of patients.

Personally, I think including an example for search via temperature range may be better since this may be more difficult for users to understand how to use.

Actually you can remove the isPersonFound attribute totally. if (personName.equals(nameToSearch) can just return new CommandResult(String.format(MESSAGE_SEARCH_PERSON_SUCCESS, personFound)) directly. If the execution of code proceeds beyond this for loop, can just throw new CommandException outside. Just a suggestion to keep your code shorter 😃

Good test coverage!

Good to include an attribute string for message usage (similar to the other commands)

Will be good to include a MESSAGE_SUCCESS attribute or something similar for the string " rooms are added in a hotel" (can refer to the other command classes to see what I mean).

E.g. in addPatientCommand your have the attribute String MESSAGE_SUCCESS = "New person added: %1$s";

So what you return is return new CommandResult(String.format(MESSAGE_SUCCESS, numPersonToAdd)) instead of the hardcoded string.

Just to clarify, this exception is thrown if the user did not call the command addnumberofrooms right?

This attribute was what I was referring to for MESSAGE_USAGE earlier. Perhaps you may need to shift this attribute to AddNumberOfRoomsCommand class instead to keep it consistent with the formatting of other command classes.

Ok actually I am kind of confused of the flow and purpose of the addNumberOfRooms command. I thought for first time user we will get them to initialise the number of rooms and that will be fixed through out the usage of the app. So addNumberOfRooms in this case should be for initialisation? It doesn't make sense if halfway throughout the usage of the app I suddenly call addNumberOfRooms command again unless I built more rooms for my facility. 😕

Actually why do you need to add code for room under AddPatientCommand?

Just curious, why did you choose to use PriorityQueue instead of something simpler like ArrayList? 😛

Good test coverage for Room!

Remember to delete this!

This will be handled by allocate person command no worries.

Nice!

If we have to convert to priority queue, do you guys think if it's better to use array list directly instead of priority queue for room list?

Right, that's true!

Should be after search patient command but it's okay for now. We will do a massive UG clean up in future as a group 😃

Will be starting with an empty "room list" or something instead of AddressBook. Just to clean up traces of address book from the code haha.

I agree with this too. There may be errors if we forget to update this variable when needed.

Neat class that adheres to format of the existing codebase!

I was just wondering why you need to have a date time created attribute for task 😛

Neat I like this!

Good test coverage.

As in I meant the attribute "DateTimeCreated" haha, like why do you need to know when the task was created 😛 . The tracking of tasks due date is by attribute "DateTimeDue".

Sounds good!

Thanks for spotting this :X

Good! We will need to add test codes for patient addition for editRoom command too.

Very neat!

Do you think it is better to write "Lists all the rooms in the application." instead? I got confused with the word 'available' thinking it meant like empty rooms without patients.

Do you want to standardise the MESSAGE_SUCCESS with that of list patient command? Like "Listed all rooms."

To add on, can even add a "Please initialise the number of rooms using initRooms command".

Allocates*, edits* and existing*. Can change only when we do our massive UG clean up also.

Removes*. Comprehensive examples given here!

Do you think we should put this function under EditRoomCommand class or should it be the responsibility of RoomList class?

Nice check! Thank you for adding this 😃

I am not sure if it is a good idea to make this function static and expose it to the outer world, considering how you also need to call the getRoomList() function from the model to get the ObservableList&gtRoom> as your parameter for this method so the roomList will be from your existing RoomList class anyway 😕. Just a thought to consider!

Very comprehensive test cases in this class. Well done!

Just curious why we need this toString() method. Is it for testing haha? But can keep it anyway.

Hmm I was thinking of having the function "isPatientAssignedARoom" in the Model interface instead. Since the Model contains roomList and the patientRecords, Model knowing whether isPatientAssignedARoom kind of makes sense (essentially it will call on another isPatientAssignedARoom method in the roomList class to get the result).

I think the key here is that the command should only know of Model and should not be accessing roomList directly. (like the Law of Demeter that we learn for this week) That's what I intend to improve for my deletePatientCommand because I also accessed the patient list directly from model, but I think it's not very well designed since there's a deletePatient command directly from model (original code from address book).

Yep no worries!

Typo: "tasks with"

Can consider "Searches all tasks before the given date."

Searches task(s)* -> I think the output may be more than 1 task right?

MESSAGE_SEARCH_TASK_SUCCESS

I think you will have to display the output in the "Tasks" tab instead. So you shouldn't be returning the result in the bot's response.

Good!

Can consider adding some success test cases and check if the output tasks are as intended.

Is it better to use the prefix_room_number from RoomCliSyntax instead since room number is an attribute of room?

Seems like success cases are covered in equals() method test.

Comparing patient to null is not very elegant, maybe check if roomObservableList.get(i).isOccupied() instead? (presumably isOccupied = true means patient != null)

Thanks for removing the duplicated messages!

Actually now I'm wondering if you do your assertion early on in the constructor, then the app will directly crash and will never reach here :X

Same issue, if you assert in constructor, will this Message Invalid room number be received by user?

If the task to delete is null, the app will just crash?

Will this crash the app?

Sounds good. I've changed the names to AddPatient instead of AddPerson for better clarity. However, if we are going to implement Staff, maybe can extend from Human instead of Person because there will be too many changes required to replace Person to Patient.

There's a possibility that comment may be a null object (since it's an optional field) and .trim() method exists for String class so it wouldn't work if comment is a null object 😛

That's a very good suggestion, will use this function in future! 👍

I followed their existing format. 😛 Since checkstyle doesn't give error, I assume it's fine?

Yes!

Yep I will change to add patient instead!

Thanks for pointing out!

I think the temp should write but the age probably no need haha.

Yes, good suggestion. We definitely should adhere to this in the next UG update!

Yep, should take note of the standardisation in UG.

I agree with Ming De I think we should stick to making sure patient does not have the same name. If we delete by index, in the case of 1000 entries, the user may have to scroll too much to find the patient (using searchpatient command doesn't show the index also 😕).

If we just ensure patient cannot have the same name, then all we need to change is the isSamePatient(...) function (to guard against duplicate patient being entered). If we need to check for the age and phone number identifiers, then we may need massive changes for deletepatient and editpatient command 😕.

Well, we can justify that the odds of patients having the same name is really very slim haha (https://www.quora.com/What-is-the-probability-of-two-people-having-the-same-name-and-also-living-in-the-same-city)

Yep yep the search room command is incomplete as I've mentioned haha. The main thing in this PR is just refactoring.

I think we will have to shift checkIfRoomPresent() to Model class also. But I will fix that in my next PR for SearchRoomCommand. The key for this PR is just refactoring.

I will change all the empty line thing. Thanks for pointing out!

Sure, I will change to "All patients are listed."

I realised search room for now is just search by room number. So it only returns 1 room haha.

I realised I should be making the pull request from my fork instead of editing directly in this repo for UG.

Incorporated with editRoom command.

Not sure why Java CI failed even though it passed on my end.

Can be closed.

Duplicated issue.

Bro that was spot on. Error was in the handleMouseClick

would it be better to remove tutorial slots part cause we don't really have a tutorial?


| `* * *` | Tutor | Delete student entries | Update my list of students if a student were to drop the module |


| `*` | Tutor teaching modules that require many written assignments | View my student&#39;s written submissions | Mark/review their homework |


            + PREFIX_TAG + "CS2103 Tutorial "

            + PREFIX_TAG + "Experienced";


**Edit Student** | `edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [t/TAG]…`<br> e.g.,`edit 2 n/James Lee e/jameslee@example.com`

I think someone forgot to change this previously...


*  `edit-student 1 t/@johndoe e/johndoe@example.com` Edits the telegram handle and email address of the 1st student to be `@johndoe` and `johndoe@example.com` respectively.

Hmm... I think putting it at the top would be more convenient for users to just take a quick look... But the word 'summary' makes it feel like we concluding something so its weird for it to be at the top... Why not change the heading to like 'Command List' or something equivalent?

I think keeping the previous would be better also... The previous formatting was based on the original user guide we got for the address book... so i think it is fine that the table and commands not consistent.

I think clear is used to clear all students though... delete is meant to delete a specific student...


#### Listing all students : `list`


#### Clearing all students : `clear-student`


#### Editing a student : `edit-student`


#### Clearing all classes : `clear-class`

Perhaps it might be good to follow the same format as DeleteStudentCommandTest to be consistent?


 * Contains integration tests (interaction with the Model, UndoCommand and RedoCommand) and unit tests for

 * {@code EditStudentCommand}.

I like how you specify that clear removes all students!


    public void addStudent(Student student) {

        students.add(student);

    }

Would this be a better name?


    public void resetData_withDuplicateModuleClasses_throwsDuplicateModuleClassException() {

        // Two moduleClasses with the same identity fields

        ModuleClass editedCS2103T = new ModuleClassBuilder(CS2103T_TUTORIAL).withStudentIds().build();

        List<Student> defaultStudents = TypicalStudent.getTypicalStudents();

        List<ModuleClass> newModuleClasses = Arrays.asList(CS2103T_TUTORIAL, editedCS2103T);

        TutorsPetStub newData = new TutorsPetStub(defaultStudents, newModuleClasses);



        assertThrows(DuplicateModuleClassException.class, () -> tutorsPet.resetData(newData));

    }

Would this be a better name?


    //// Student related tests

'''suggestion

/**

Wraps all data at the application level.
Duplicates are not allowed (by .isSameStudent and .isSameModuleClass comparison).

Perhaps a line break here will make it look less cramp?


        Index outOfBoundIndex = INDEX_SECOND_ITEM;

        

        // ensures that outOfBoundIndex is still in bounds of Tutor's Pet list

        assertTrue(outOfBoundIndex.getZeroBased() < model.getTutorsPet().getModuleClassList().size());

should this be


    // identity fields

same for the data fields comment

Perhaps this comments and the few below should start with lower caps?


        // one keyword

would it be better to leave a line here?


       

         // manually link first class to first student

        ModuleClass moduleClass = model.getFilteredModuleClassList().get(0);

        Student student = model.getFilteredStudentList().get(0);

        Set<UUID> studentUuids = new HashSet<>(moduleClass.getStudentUuids());

        studentUuids.add(student.getUuid());

        ModuleClass modifiedModuleClass = new ModuleClass(moduleClass.getName(), studentUuids);

perhaps this comment should start with lowercase?


    private TypicalModuleClass() {} // prevents instantiation

perhaps this should start with lowercase?


    // manually added

Perhpas this is missing a full-stop?


    // Manually added - Student's details found in {@code CommandTestUtil}.

perhaps this should start with a lowercase?


    public static final String KEYWORD_MATCHING_MEIER = "Meier"; // a keyword that matches MEIER

Perhaps this would be a better naming?

''' suggestion

public void execute_indexSpecifiedListIsNotFiltered_showsStudentsInClass() {


    public void execute_invalidIndexSpecifiedClassListIsNotFiltered_throwsCommandException() {

Would it be good to specify which list?


    /**

     * Removes all {@code studentUuids} from each and every {@code ModuleClass} in the class list.

     */

Perhaps student manager would be a better name?


    /**

     * Removes all {@code Student}s from the student manager.

     * Also removes all {@code UUID}s from each {@code ModuleClass}.

     */

I am not sure about this... But should the full-stop be after the example?


    /**

     * Ensures that Tutor's Pet will not be able to boot up given an incomplete {@code UUID}

     * (e.g "0c527a3f-8a6f-4c16-b57d-").

     */

Perhaps it will be a good idea to keep the formatting consistent with the subsequent tests?

'''suggestion

/**

 * Ensures that Tutor's Pet will not be able to boot up if two or more {@code Student}s are found with the same {@code UUID}.

 */

"something is wrong" feels a little generic.. Perhaphs it is good to specify?


            // Check that the set of student UUIDs within a class is a subset of that of

            // all student UUIDs in uniqueStudentUuids. Otherwise, Tutor's Pet would not

            // boot up due to data corruption.

would canUndo_noPrevState_returnFalse() be a better name for this test so as to keep it consistent with the other namings?

would undo_noPrevState_throwsUndoStateException() be a better name for this test so as to keep it consistent with the other namings?

should this use case resume at step 1 instead? since user will need to request to edit a specific lesson again..

should this use case resumes at step 1?

should this be attendance record?

Perhaps to keep it consistent with other constraints message we can use


    public static final String MESSAGE_CONSTRAINTS = "Days should only contain capital letters.\n"

Perhaps it is a good idea to keep the javadoc comment consistent with JsonAdaptedModuleClass..

'''suggestion

/**

 * Converts a given {@code Lesson} into a {@code JsonAdaptedLesson} for Jackson use.

 */

Perhaps it is a good idea to keep javadocs consistent?

'''suggestion

/**

 * Every field must be present and not null.

 * Creates a new lesson with the specified parameters.

 */

Perhaps it would be good to use another class index here instead of both 1s so that it is clear the last index is accepted?

Is it possible to static import this?

as well as the few below...

70 feels like a magic number... Do u mind changing it to the constant VALID_PARTICPATION_SCORE_80?

same for the ones below... and the 1000 could be change to INVALID_PARTICIPATION_SCORE_101...

Not sure if this would sound better...


A `TutorsPetState` object contains a Tutor's Pet state, along with a message that describes the changes relevant to this state.

Is there extra spacing here?

Not sure if this would be better...


It contains the `Attendance`s of all `Student`s who have attended the particular lesson.

not sure if this sounds better...


* After finding the class CS2103T and student Alex, you wish to view all your students and classes.

Hence, you type in the command `list` and and press <kbd>Enter</kbd>.

just a suggestion...


* Now you can see all your students and classes.

Should we put these few points under a Constraints: section?

Would this sound better?


* Alex is a student in your CS2103T class. After your lesson in week 1, you wish to give him a participation score of 45.

should we specify that the score is for participation?


* Now you have successfully edited Alex's participation score from 35 to 45 points.

Not sure if this would sound better...


     * If the {@code studentToRemove} does not exist in the {@code attendanceRecord}, the {@code attendanceRecord} 

      * remains unchanged.

Not sure if this is correct but I referred to ur previous javadoc for inspiration...


    /**

     * Returns a {@code Lesson} where the {@code Attendance}s of the {@code studentToRemove} have been removed.

     */


    /**

     * Returns a {@code Lesson} where all {@code Student}s have been removed.

     */

Not sure if invalidStudentToRemove or targetStudentToRemove would sound better...

Perhaps this would be better?

'''suggestion

/**

 * Creates a {@code Lesson} with the given {@code lesson} and {@code displayedIndex}.

 */

I guess the refactor cant detect that... THANKS!

HAHA cause dexter added that in his i think

That test was missing so i just added it and made it consistent with what was in EditStudentCommandTest

Issue #156.

I am going to do another PR to change the rest but since I was in that document I thought maybe could change that first...

not sure if thursday 2pm - 4pm: weeks 1 2 3 4 5 would look better?

Manually copy from the result display box

UPPER_CASE shoudnt be in markdown

There is no line breaking here.

LGTM

quick start should start with ##

The contents should be hyperlink

I will add the hyperlinks

the list should have the ``

I think there should not be indentation here

Should it be "the list of all tasks"?

should it be "list all tasks"?

Same as above

are we going to skip displaying or just display an empty list? If we are just displaying an empty list, is it still considered an extension?

list all tasks

the list of all tasks

same as above. i'll ignore it for the following parts

Is 'exit' inside the use cases? should we add it?

This is still not changed

The class here is still not changed to Task

Why extra indent here?

Why extra indent?

same here

nice!

Should we use trimmedTitle instead of trimmedName?

Do you wanna change "address book" to "PlaNus" now or do it later?

Does the name "fullTitle" make sense?

Why extra indent?

just to check, the corresponding UI class variable is also changed right?

What's the rationale of changing it to Amy?

agree. and better put date as yyyy-mm-dd

the attribute in the userguide says date: tho

Should have clearer documentation here

Clearer documentation pls.

Why is this private variable in between to public variables?

I think a better documentation is : construct an empty Description when user didn't provide the description field. Caveat: Only called when the user didn't key in this field.

Same. private variable in between public variables.

Same. I think the documentation can be better.

I would recommend making this documentation clearer as well. Add another line to specify that this is only used to construct an empty Phone when the field is not in the task.

Nice that you changed the UML as well.

oops, I think this should have been "description". My bad I forgot to change this. Can you change it?

Should we really allow type to be any string? Or just one word letters connected by '-'

Is there a reason to keep a counter? Don't we just need to traverse through all the types?

iirc there's a "requireNonNull" method there? Can we use it?

hmmm maybe you can consider using the join method?

Maybe you can consider using the "join" method?

I think we are changing all these to PlaNus

We can. But I don't think its a big issue as long as there is no bug. Stringbuilder looks cleaner tho I would say.

Maybe add another extension when the task index supplied is invalid?

I think there's an extra '/'

Are you throwing any CommandException here?

What are the B, C and D for?

Will there be any case where a valid user input will make any of these null?

Missing period at the end.

I think you can use the formatter from the DateTime class if possible

No need day of week?

should be lesson right

Should remove this

Actually, I think we can make the Time, Date and DateTime class inherit or implement a common interface. Maybe I'll refactor this later.

Why use plural?

Should I just delete it or mark it as coming soon?

got it

nice catch

resolved

sry this was a mistake. I changed it. the datetime won't be null

Just mark it as done when you finish your part

What are left to be done for the use cases? Maybe can add inside description?

Completed

Can you push the branch to the team's repo so that we can pull and test locally?

Also codecov seems to have dropped. Maybe can add some relevant test cases to bring it back?

This has been completed in #73

The error message doesn't quite match the actual error.

I think also need to update the DG

Could you change this instance of 'AddressBook' to 'Athena'?

Change this instance of 'AddressBook' to 'Athena' as well

Adds &gti>an&gt/i> event instead of &gti>a&gt/i> event

Consider adding Javadocs to this method and the newly implemented methods below

What exactly is this change?

Please commit only relevant changes to the branch in the future. This is probably more relevant when adding the editEvent command

Add class-level javadocs for this class

Update this javadocs for the context of AddEventCommand

Use the &gtcode>// some comment&gt/code> for this instead of &gtcode>/* some comment */&gt/code> as that is relevant only to the method/attribute right below it which in this case is &gtcode>PREFIX_DESCRIPTION&gt/code>

Please include class level Javadocs for this

Consider placing this into the constructor?

Update javadocs to specify calendar

Update Javadocs to specify it is about events not persons

Add class level javadocs to tell us about the class

Add class-level javadocs to tell us about the class

What is the difference between these two methods? Should the &gtcode>setEvent&gt/code> method check 'equality' between two events and replace the one in the list with the one outside?

I believe this replies to the wrong part of the review? Please use this only to reply to the specific comment above

Consider adding this method and the test methods below to a separate class called &gtcode>AddEventCommandTest.java&gt/code> to separate tests for Bangyi's &gtcode>AddCommand&gt/code> and tests for your &gtcode>AddEventCommand&gt/code>.

Consider adding these messages as constants instead of magic literals

Is the prefix necessary at all?

Should be able to obtain the index directly similar to the Delete command for example

This seems to be outdated compared to what is actually implemented

Would be nice to have a brief Javadocs description of the class

This Javadocs is outdated

Should probably remove this as it is not used at all

Should remove this from the interface and the implementing classes

Should probably remove this as it is only used by the unused sortPersons method in AddressBook

Should probably remove this as it is not used at all

This method should probably take in a Comparator instead in line with how the updateFilteredPersonList method works. Model Manager shouldn't need to know exactly which Comparators it needs

The three comparators should probably declared as static constants within the SortCommand class itself?

This should probably be done in the SortCommand class itself. execute chooses the appropriate Comparator in the execute command to pass to ModelManager.

Does each class really need to know the COMMAND_TYPE string? It seems like it would be better to just have the AddressBookParser store the main COMMAND_TYPE string variants. Either that, or these classes should be taking the AddressBookParser's COMMAND_TYPE definition. Because right now, to change the COMMAND_TYPE string, every single file has to be edited

And it seems that the COMMAND_TYPE String is largely not used except to reconstruct the equivalent user input

I would suggest something like -c and -e instead of /c and /e as I believe we should differentiate field specifiers from object-type specifier. Especially since add /c n/some name looks kind of strange

My suggestion was actually to not have this at all. But the enum-type would probably be the second best alternative as both AddressBookParser and the relevant commands will depend on the String specified in the enum-type. Because as is right now, the current implementation is the equivalent of the cyclic dependency you mentioned, just not strictly coded in. If you change AddressBookParser's string to detect Contact-type commands, then you'll still have to change those within each Contact-type command class.

If you're removing references to the Command-type string inside the Command classes themselves, then the reconstruction of user input tests have to be moved to AddressBookParserTest instead. The individual Command-types will handle only their own share of input (everything that is after {command name} {contact/event}

I think only one enumeration is sufficient (CommandType). Because 'add' is a unique identifier for the AddContactCommand, or at least it was. But I feel like the reason both AddressBookParser and the individual command classes should not hold the contact identifier's specific implementation within them is that it is a property that they all share and depend on. So a separate enumeration would fit this.

I change my mind regarding holding references within the command classes themselves to their CommandType. It does make recreating the command for testing easier.

i think there is merit in having the test cases remain in their current classes as they are intended to test certain classes.

I don't think this is really relevant to the discussion because the individual command classes don't actually use their own command word and command type for testing. Only AddressBookParserTest uses them to recreate it.

specifically, i believe it should be

public static final String COMMAND_WORD = CommandWord.SORT.toString();

public static final String COMMAND_TYPE = CommandType.EVENT.toString();

would it be possible to add the 3rd line into a separate branch to continue working on? as you have mentioned that it is not quite implemented yet. So we should merge only things that fully work to master

Related to the above comment, to add this to a separate branch and subsequent PR so it is obvious to us what the changes are in the future PR.

although i think it would be better to have the detection of invalid inputs handled in SortEventCommandParser.parse.

the SortEventCommandParser.parse is already implemented. But I do agree with the suggestion regarding the default branch. I think it is in-line with defensive programming to reserve the default block to throw an exception instead in order to protect others who might be using the code.

This comparator does not seem to match the description specified in the indexMessage(Index) and MESSAGE_USAGE. This seems to compare the number of tags instead of the number of participants.

This doesn't seem to have any indication of the actual number of participants though? It seems to mostly just compare the tagName string-wise. To get the actual number of participants from each tag, I believe you need to use the model.getPersonsWithTag(Tag) method to get the actual Set&gtPerson>

but tags are not the same thing as participants?

Also the comparison itself seems kind of strange. If o1 has 5 tags and o2 has 10 tags, this falls under the last branch which compares only the first name of the first tag found in the set. Also, I believe this is prone to changing as Sets do not have a well-defined order.

I was under the impression Events would hold a Set&gtPerson> (added without any specific tagging) as well as a Set&gtTag> (of groups of participants identified by the tags). The total number of participants would then be a conjunction of all the participants found from the Set&gtPerson> and each Set&gtPerson> belonging to each Tag.

I believe this is a typo

It seems to me that this comparator has some issues. In particular, the tags are actually stored in Java's Set which has no guarantee of order preservation. So this could result in different comparator results on different calls of the compare method.

I believe this might be related to the same Comparator in SortContactCommand

Additionally, consider creating a PersonsComparator class which stores all these comparators as public static constants so that both sort commands can refer to the same Comparator object.

consider using case 1: return NAME_COMPATOR;... and throw a CommandException for the default branch. This can potentially safeguard the code from misuse by other developers.

Will this fail if a sort is performed on an empty Athena? Perhaps, it should instead just not do anything if the list size is 0.

I believe the name of the method would be more appropriate as something like permSortContacts or permSortPersons as we will eventually need to remove instances of 'addressbook' within the code. Additionally, I believe the argument name would be more appropriate as something like comparator as chooseComparator sounds more like a method name.

Would be nice to include test cases that check against the permanently saved file to see if using the command changes it.

Is there a guarantee that the first tag being displayed in the GUI is the same as the first tag found in the set.iterator()?

On a related note, I wonder if this comparator is necessary because it seems quite arbitrary. I was going to suggest perhaps some sort of way to request sorting in the reverse order, so the name comparison would put Z at the front etc. In this case, I think a comparator that allows sorting by number of tags might fit this better. Though I am unsure how this might be useful as well.

Do reflect these changes within the origin SortContactCommand as well. Thanks!

There is an additional '9' here. Also consider leaving a line between the class declaration and the first javadocs

Consider changing the description to be something more explicit like: "Permanently sorts and edits the underlying save person-list save file" to clearly say that this changes the save file.

Also consider changing the argument name to just comparator instead of chooseComparator

This internalList assertion seems slightly problematic. Given an invalid json save, the json save would be wiped out and replaced with an empty json save. This will create an internalList with size 0 which seems common enough to not warrant an assert. Perhaps a simple assert c != null would suffice.

As it turns out, private comment Javadocs are not really standardised throughout the code. I think this is not a big issue

it is a runtime exception. I do not believe it is necessary. Especially since there should be no reason why this exception occurs at all if Person changes are done through AddressBook.

Is there a difference in wrapping in an Optional? It would still be

Optional.ofNullable(tagPersonSetMap.get(tag)).orElse(Set.of()) which I don't think is much better

Ok, as it turns out it's only one instance from the original. The description of the getFilteredList() from the Model interface. I'll change it

This was supposed to be 'contains only tag-person mappings from the persons list.' The original message was not written very well. Thanks!

yes, thank you very much.

or would be appropriate, thanks for pointing this out

I think the individual behaviors have to be explicit. In this case, the upcoming editTagCommand will specify tags to add and tags to remove as two separate tag sets. As such, I wanted to be clear here on the behavior of the method for each case.

The documentation of these methods' purpose is in the TagTree abstract class. I wanted to leave open the implementing class in the event someone could come up with a better underlying system for it. Admittedly though, many classes do depend on associate with TagTree and as such, depend on TagTreeImpl anyway.

i am genuinely unsure about this. Perhaps you could decide and tell us? I do believe the original JsonAddressBook class uses json instead of JSON.

Issue has been fixed! Thanks for the notification. I ticked the 'Require status checks to pass before merging' option without realizing that I had to specify which CIs I wanted passed before being able to merge. This has been addressed and our CI is now passing.

Is the sort method supposed to sort the current shown list? Or is it supposed to sort the full list of contacts before showing it? Because the former would be much easier to implement and I believe is what we intended to do originally? There is the model.getFilteredPersonList() method which gives the last shown list.

Also, I agree with the Hendey's comment about the sortPerson method. I do not think that all the model classes need to have such a method.

Please settle the merge conflicts by including both methods for the two different conflicts. Then it'll be good to merge. Thanks!

Looks good to me. I'm just wondering how the TagManager class helps to keep track of the participants (persons) of a particular event without implementing necessary changes in Calendar class or respective events class?

This was done mostly with the context of supporting Bangyi's delete by tag and add to events by tag. Shouldn't the Event's class have references to the Tags it contains similar to the Persons it contains? Anyway I believe someone else is implementing this. This was just to help support that.

I don't really agree with this. I believe that we should limit the options the user has in this case. Otherwise, suppose a user creates a tag Cs2103 and starts assigning things to it. This tag will be permanently stuck at Cs2103 and unless we give them a new command to change the specification of the tag name to either CS2103 or cs2103.

Not to say that forcing upper-case is definitely a better solution than what you suggested, but I do feel that enforcing capitalization is a more agreeable policy as opposed to someone not realizing that they can't change the capitalization of their tags after adding hundreds of contacts under the tag.

Upon further deliberation, I realize that an edit tag name-type command is inevitable. As such, this should cover whatever I was concerned with initially. Thanks for the suggestion!

On further further deliberation, I realize there is still a necessity to standardize the capitalization of tags. When two separate Persons are added with tags cs2103 and CS2103, should a lookup of the tag produce both? Otherwise, if yes then why not standardise how the tags themselves look. If no, then I personally feel that it kind of beats the point of implementing search by tags to begin with.

Looks like theres a formatting issue here

I think we should turn the 4 into a constant, i.e. private static final CALORIC_MULTIPLIER = 4. Same for the rest of the macronutrient classes

Similar to the toString function, I think we can factor this out to the superclass. If we do that then we can also change all its protected access modifiers to the ideologically superior private.

Looks like you're using the assertion incorrectly, it should be

assert amount >= 0 : "amount cannot be negative"; instead.

Currently it will print the error message regardless of whether the assertion passed or failed.

Also a side note: we should use the java logger instead of System.out.println apparently.

Maybe you could add a TODO comment on what kinds of methods to add to this class/how it should be used.

e.g. // TODO: Food FoodMethodHandler.combineFood(Food firstItem, Food secondItem) or something

IIRC we need to write javadocs for each class according to the module specifications.

IMO we should keep this as the string "Carbohydrate" instead. Makes the code more explicit.

Same for the other macronutrients

I think we should @override the object.equals method instead. Having 2 methods claiming to do the same thing will invite bugs.

This method only makes sense if we have unique objects in the list, maybe you could change the target to the Index of the object in the list, or require all objects in the fridge to be unique.

Same as the setFood method

I think we should rename this to macronutrientType or something so we don't confuse this type with a java type.

Assertion here could be more descriptive (e.g. "Macronutrient type cannot be blank"), since we are changing name to type.

We should be checking for referential equality here i think? i.e. assertTrue(expectedFridge == fridge), not sure if object equality is intended.

Same as below comment

typo in caloriMultiplier.

Also I think you MacronutrientStub or something would be a better class name. The current one sounds like this is an object that creates other macronutrients.

Should remove this or put a TODO comment if its blank

I think this should be withFood or something

Also is using person here intended?

I think a comment would be good here to say it takes the name from the class name

Maybe we should change int index to Index index, i.e. the class from AB3.

I think we should keep this as just assertThrows instead. We should stick to the static asserts for tests

same for all the other test files that were changed

hmm we may be able to abstract this part a bit more in the future, just a note, no need to change now

this is not an email !

I think we should be using getNutrientValue here instead?

this method violates DRY, we should really remove this

this is important

can't see clearly in the diff but I think we're missing a javadoc here

We should extend Exception instead because they are checked

extending RuntimeException will lead to a lot of very painful uncaught errors

Same as the other DuplicateFoodException, RuntimeException is very spooky

I guess this is valid but should we leave this or change it to mcspicy or something

same as invalidFoodMcGymmy, i think we should use actual food names here

same as the .json files, we should change to food values

Maybe change the names and tags here as well to food

As above, I think we should change these names

could abstract this into a method hasDuplicates in ReadOnlyMcGymmy or its superclass

this should be if (food == comp) for referential equality (the is operator in python).

Comparing the hashcodes does not guarantee the food and comp are the same object in memory.

As with the other files, should change this to food.

should change all these to resemble the typical values, except with an underscore, space etc.

i.e. each test should only have 1 reason to fail.

Should use the module convention, i.e. protein_isValid_correct or something

Same for the methods in the other test classes

Need to change these examples too

We should change all these names/values to food ones.

Should be Carbs.MESSAGE_CONSTRAINTS instead here, same for fats below

i think toString might override the java object's default method, so that might cause problems (including confusion in developers)

maybe we could use the module convention toString_isCorrect or something instead

maybe something more useful here could be to set a boolean flag hasBeenUndoed or something to true here, and checking it in the execute_canUndo_success part

I think we can shave off the parsing part bc it would have been mentioned in the above sections.

Makes the diagram less packed

there seems to be a typo in the file's name itself (it's FIndSequenceDiagram.png in the folder or sth)

This part maybe can go higher level (remove specific details on which methods get run and just say what happens, e.g. "it combines the predicates then filters the list"?

Also for the diagram itself may be able to shave off the parsing part (i.e. only show what happens after the .execute()) because it will be repeated in the previous section

I think we can change this to a for loop where we delete using the filteredList's predicate, i.e.


var predicate = filteredFoodItems.getPredicate();

for (Food food : listOfFoodSomewhere) {

    if (predicate.check(food)) {

      removeItem(food);

    }

}

This will work as intended, as long as getPredicate and setPredicate in fxcollections works as intended

Can also create a public void filter(Predicate p) in Fridge.java then call it somehow in this method.

Then we can use java streams to filter and override the list (but don't forget to invert the boolean predicate).

I think with the new implementation we can delete this method and the other related one in Fridge

Remove this method then should be good to merge

I think for this long chain we can replace it with a stream/list of all the above predicates + a stream.reduce call.

Will be much cleaner

For these changes is it due to the "" OptionalParameter misbehaving?

Perhaps we could log that as an issue and address it in another PR. Don't think hardcoding these exceptions are a good idea.

A suggestion I have is to collect all these Predicate classes into 1 file and turn each individual Predicate class into a function that returns an anonymous class, i.e.


public class Predicates {

  public Predicate<Food> makeDatePredicate(String date) throws ParseException {

    return new Predicate<Food>() {

      // all the code below

      }

    }

  // ... more predicates

}

Will reduce a lot of the java boilerplate in the codebase.

Hmm looks like I may have accidentally removed this during the safe delete or something, will update and restore it.

Yes that seems to be better. Good catch.

I'll add a couple more tests for this, along with some unit/integration tests with the Commands.

Nope, if you try to declare multiple of the same parameters there will be an assertion error somewhere.

Technically you can work around this, by declaring a new class that contains the two parameters, e.g.

the command:

takeTwoIntegers 1 2

may have a parameter

private Parameter<IntPair> param = this.addParameter(..., IntPair::parse)

and the IntPair class is as follows:


class IntPair {

  public int a;

  public int b;

  public parse(String str) {

    IntPair result = new IntPair();

    result.a = ...

  }

Don't think any of our commands will involve these kinds of parameters, but if they do we may have to either redesign the command or the parser. (We'll solve that problem when it happens)

Yes, for the first one the 1 will be considered as input to the -n parameter, and the unnamed parameter will have no input (so there will be an error).

I'll add this and the comment below into the PR's docs.

No point imo since I'm not reusing the string outside this function.

Also would add more noise which we're gonna change anyway (when we change people to food).

yup you're probably right. I mustve copy pasted wrongly somewhere

for tests we usually just throw Exception because if any exception happens JUnit will catch it and display the error message and error type.

Its more convenient to do this and also we don't need the extra type checking for the specific error thrown (DataConversionException).

the list is final though, so then we will have to unfinalize it

also this is consistent/the same as the implementation in JsonSerializableMcGymmy.

good job

Added a skeleton to Duong's PR. Should be able to add on from there while avoiding merge conflicts.

(related note: can someone approve that PR? don't think I can do it because I also contributed a commit.)

We should use the same format as the one from AB3 (copied over below).

Use case: Delete food

MSS

User requests to list persons
AddressBook shows a list of persons
User requests to delete a specific person in the list
AddressBook deletes the person

Use case ends.

Extensions

2a. The list is empty.

Use case ends.
3a. The given index is invalid.
- 3a1. AddressBook shows an error message.
  
  Use case resumes at step 2.

The CI test says that you are missing the shadow plugins

Seems like a github actions issue. This happens from time to time.

Closing and reopening the PR should restart the CI process (hopefully fixing this).

LGTM

I think I can do this easily using the new logic architecture

Preliminary findings:

This is actually a symptom of a much bigger problem: the code is violating SRP and Seperation of Concerns.

Context

Right now the model classes (i.e. Fridge, UniqueFoodList) are throwing these RuntimeExceptions when the food being added is a duplicate etc.

The reason why this has not been a problem so far is because (for the case of the DuplicateFoodException) the 2 classes that add to the food list/fridge, the AddCommand and EditCommand have guard clauses that throw an error when a duplicate food item is being added.


if (!(foodToEdit.equals(editedFood)) && model.hasFood(editedFood)) {

    throw new CommandException(MESSAGE_DUPLICATE_FOOD);

}

this one

Frankly this shouldn't be the job of the EditCommand or AddCommand and now we have to include extra tests to ensure these guard clauses work.

Using the current design, in the future if we add more Commands or other functionality that add food items to the model, we will have to keep in mind to catch these duplicates ourselves else oopsies! the program will explode because Fridge threw a RuntimeException.

It is my firm belief that since Java so benevolently offers to handle these problems for us (with checked exceptions), we forgetful humans should gracefully accept its help.

Note: I just remembered we're allowing duplicates now but the above argument still applies to the other FoodNotFoundException.

Proposed Change

Recall the current guard clause used:


if (!(foodToEdit.equals(editedFood)) && model.hasFood(editedFood)) {

    throw new CommandException(MESSAGE_DUPLICATE_FOOD);

}

If DuplicateFoodException is thrown as a checked exception, we can easily wrap it in a try-catch:


try {

    // do the adding here or wtv nonsense

} catch (DuplicateFoodException e) {

    throw new CommandException(MESSAGE_DUPLICATE_FOOD);

}

Copied over the justification from AB3


PersonNotFoundException is a checked exception. It is thrown by methods

such as `UniquePersonList#remove(Person)`,

`UniquePersonList#setPerson(Person, Person)` etc. to signify that

certain preconditions were not met -- namely that the person provided to

those methods does not exist in the address book/UniquePersonList.



Using checked exceptions for such a purpose is slightly useful in that

it will force callers to handle the case where the above preconditions

are not met, such as when the methods are called with invalid user

input.



However, it imposes a HUGE cost on callers where the preconditions are

already known to be met (e.g. in test code, or when the user input has

already been validated before hand). In such a case, callers are forced

to add try-catch blocks around the method call even if they know that

the exception will never be thrown, bloating up the code. It is also

impossible to test the catch blocks as well since correct code will

ensure that the precondition holds and thus the exception will never be

thrown, leading to reduced code coverage.



Checked exceptions also don't work very well with the Java Streams API,

since the API doesn't accept lambdas which could throw checked

exceptions.



In AB-4, the amount of code which benefits from PersonNotFoundException

being a checked exception is much smaller than the amount of code which

is negatively impacted.



As such, let's make the tradeoff in the other direction, by making

PersonNotFoundException a RuntimeException. New callers _could_ forget

to check that the preconditions hold before calling the methods in

question (although test cases should catch that), but this is balanced

out by the huge benefit of having more concise and testable code.

Only argument I agree with is the Java Streams one, but we can work around this.

We can discuss this in the next team meeting.

Will make this a not draft after I add some tests or something maybe

The code is mostly formatting text to be printed so I dont think unit tests will benefit it much

Once we merge this we need to add a new issue since the executeCommand("help") is hardcoded for the button

e.g. find -date 2020-11-11 -tag lunch

e.g. find rice -date 2020-11-11 -tag lunch

FRONT MATTERS (Team 20%)

Clear and concise statement of the purpose of the document, and the target audience
Clear and concise user-centric statement of product information, e.g. product description and overview of main features
Clear and complete information about how to use the document, e.g. how to navigate the document, meaning of icons/formatting used.
Clear and complete information about how to get started, e.g. installation instructions, parts of the GUI, tutorial on how to use CLI, etc.
Shows reader consideration by going the extra mile to provide other necessary information, or to make this section welcoming and appealing to the reader.

INSTRUCTIONS for each implementation (Individual 50%)

clear and user-centric description of purpose of feature/function/command
Clear and easy-to-follow step-by-step instructions for at least one example
Clear, relevant, and helpful graphics. Visual and/or textual cues are used to indicate which graphic(s) go with which set of instructions.
Heading, instructions and examples are customized to the application
Highly considerate of user’ needs by providing other relevant and helpful information e.g. warnings, tips, important note.
Highly considerate of users’ needs by using formatting (font style, size and color, mark-ups, callouts, bold, italics, etc) and layout (white space, alignment, etc.) to maximize readability.
Well-chosen, accurate and reader-focused language.

PRESENTATION (Team 10%)

Consistent terminology throughout the document.
Consistent formatting (symbols/icons, font type and size, colors, image size, use of mark-ups and callouts, bullets, etc.) and layout (alignment of text and graphics, white space, paragraphing, etc.) throughout the document.
Easy to navigate (e.g. provides hyperlinks where necessary or expected, Table of Contents is accurate, etc.)

LANGUAGE, STYLE AND TONE (Team 10%)

Consistent phrasing of headings and sub-headings throughout the document
All headings and sub-headings clearly and accurately indicate content of each section
Consistent user-centric style and tone throughout the document, e.g. you-language, active tense, short sentences, etc.
Correct grammar, punctuation, spelling, mechanics throughout the document

OVERALL (Team 10%)

Document is highly attractive, pleasant to read, and easy to understand.
The document leaves the reader with a highly positive impression of the product and the team.

edit here https://github.com/Jh123x/tp/blob/User-Guide-v2.0/docs/UserGuide.md

TODO: will move MacroList into the model in the next PR.

Do we want an option to find before/after a certain date? i.e. show all foods created before/after a certain date?

Or we can put this in another PR/not do this at all.

likely this is the cause #112

Also we should make it such that each command is undoable and document this in the UG. Easiest solution

note 1: problem because filtered list for both actual/expected model has size of 1.

update: list actually not getting filtered properly

Shouldn't the text name for this be matriculationNumber?

Maybe INVALID_MATRIC_NO could be changed to INVALID_MATRIC_NUM instead?

Shouldn't there be a method call withMatriculationNumber(...) as well?

Perhaps MATRIC_NO_* could be changed to MATRIC_NUM_*?

Should there be an awkward line break right after MATRIC_NO_BOB? Same issue with the other test cases.

Shouldn't there be a method call withMatriculationNumber(...)?

Shouldn't the message be ATAS has deleted all students! or something like that?

Perhaps these could be renamed to ACCEPT_COMMAND_FULL, ACCEPT_COMMAND_SHORT, REJECT_COMMAND_FULL and REJECT_COMMAND_SHORT?

Perhaps comments could be added to explain what you're testing for each statement (+ expected result)?

I noticed a similar issue previously. Maybe more comments explaining each test case could be added?

Do you think it would make more sense to include the use of the abstracted wrapper class Index here?

Would this make more sense to put in an if-else block (with comments to describe the else block)?

Should this unncessary extra line break be removed?

Maybe these could be renamed to PREFIX_SESSION_NAME and PREFIX_SESSION_DATE?

Shouldn't the form be dd/MM/yyyy?

Maybe some comments could be added here to more clearly explain the thought process?

Unnecessary additional line break?

Maybe these two if blocks could be merged into one?

Would it make more sense if all instances of SESSIONNAME got changed to SESSION_NAME? (same for SESSIONDATE and SESSION_DATE?

Unnecssary whitespaces?

Unnecessary whitespaces?

Unnecessary extra line break?

Unnecessary line break?

Unnecessary whitespaces?

Shouldn't this be renamed to Editing a student to fit the rest of the item naming?

Maybe this class could be made public?

Shouldn't the command participate be in all small letters?

Shouldn't this be enterses?

Shouldn't this be presence?

Shouldn't the command here be editses?

Maybe you could add a TODO for next time?

Should this be something like saveStudentList?

Maybe change this to JsonSerializableStudentList and correspondingly ReadOnlyStudentList?

addressBook -> studentList?

AddressBook -> StudentList?

addressBook -> studentList?

Maybe this could be changed to Clearing the student list?

Maybe this could be changed to Delete Student, seeing as we are deleting one student at a time?

Perhaps the last comma could be changed to a full stop?

Maybe this comment could be deleted?

Maybe this comment can be updated since we're no longer using a hash map?

Maybe this comment could be deleted?

Thanks for pointing this out, as well as in other places!

This implementation is under the ModelStub and this method is not used at all, so I thought returning null wouldn't make much of a difference either way.

Do you have any alternative suggestions for this part?

Same as above:

This implementation is under the ModelStub and this method is not used at all, so I thought returning null wouldn't make much of a difference either way.

Do you have any alternative suggestions for this part?

Did I not add it in? Lines 22-24.

Is it better to change this sentence to this?

"This project is based on the AddressBook-Level3 project created by the SE-EDU initiative."

As I feel like this flows better for me.

Should this be linked to our repo's actions instead of the se-edu's one?

no i mean the link not the badges. Now you are linking it to se-edu/addressbook-level3

https://github.com/AY2021S1-CS2103-T14-3/tp/actions

this

I think this line can put?

I'm a bit not sure about this. Is it we can edit the travel plan at top directory also?

dk hahaha

@jiaweiteo @jeannetoh99 @timjkong

According to @jiaweiteo , only the name should be considered as identity fields, while passport and phone should be data fields

i think its better to put getTPOList()

same for all the other TPO

Is it better to have ScrollPane here? As we might have lots of TravelPlan and the Pane cant show everything

Same as above. Maybe we put ScrollPane here

JavaDoc errors

We just need one method from Directory only? What about AccommodationList all that?

Is there a better way of doing this? Like not typecasting but instead use the polymorphism.

Why did you use assert here btw? Cos I think assert won't be run if we didnt specify it and the user probably wont run our program with assertion on. Maybe check it using if block and throw an exception? Same for all the methods below

JavaDoc error

same for line 57

JavaDoc error

thats why before i put 2 boolean method to check is which one

nah typecasting is not considered polymorphism. We have to do directory.the method straight away i think. But it might be not worth the time to think about that. So maybe can leave it like this first ba

oh okok then Logic is the one that have to make sure the directory is the correct instance?

Why this one change back to TravelPlan? It's not used in other place meh? like Activity all that

Oh I see what you did there. Works but I feel like it is not following some OOP shit or smth. But I think we come back to this later ba.

I think the cost is just numbers? iirc

Do you think we want to make the arrangements of all these fields consistent throughout our whole repo. Cos I feel its a little bit messy right now, everybody's arrangement is different.

@jiaweiteo @jeannetoh99 @underthehai @timjkong

Same as above

Is it travel plan list?

I think it is suppose to be start date and end date?

We use -1 to indicate no changes, but here we throw an exception? Would it have any problem?

There is an extra whitespace in front of Activities?

Here also. Or is it deleted whitespace haha i not sure

Why the whitespace!!!

The Ui didn't show the index actually, do you think we wanna show it? Then, need add into Ui part

But why previous one no problem one ah? hmmm

Can you make the wish list "wishlist" instead? I think we use wishlist.

CopyCommand perhaps?

Do you think its better to use guard clause here instead of if else statement?

Same as above

JavaDoc issue: "address book"

I think this can rename to SHOW_ALL? I remember I changed it to SHOW_ALL don't know when get changed back haha

NameCard should be under TravelPlannerPanel

These 3 should be TravelPlanObjectListPanel

There is a space in front of -tra... ? Cos I tot just "-travelplan 2"

No, its not. You go check the implementations in Ui component

oo okok cos i think i didnt put space in front of mine

Actually, I might try to change it so that there isn't so much magic number here and there, using the ArgumentTokenizer, cos you guys didn't utilise it i think?

Hmmm is this image name correct?

Need, but i thought haishan is also doing this so I left out the edit and show features for her, or I should just do them?

Hmmm I don't know.

@jeannetoh99 @underthehai @timjkong

Maybe can add the person to be deleted is not found?

You mean the person is not found in the travel plan or you mean the person is missing in the input command?

I will add the case for target not found, but the error message one cause I wanted to make them generic so don't need to be too specific. The implementer of that feature can do whatever they want to the error message. What do you think?

@underthehai

I updated it. But I don't know if it works, can help me check?

oh cos this method is I cincai add one last time. No JavaDoc all that, need to redo

Actually I changed all to without all the Wanderlust in the front. Tsk didn't read my telegram message. YOU SHOULD CHANGED!!! NOT ME!!! HAHAHAHA

They are included in the etc XD or else too long lah, or you think I should change the commandbox all that to travelplan thing?

My CI will pass after merging @jeannetoh99 TravelPlan class

Don't merge first after commiting changes.

I need to think about all the ReadOnlyXXX classes, if they are needed

I think I'm done for now? Hopes everything works.

And do you think we need to make sure that the travel plan inside travelPlanner needs to be updated too?

I closed ah, I have added them in my side

I think the commit is messed up, cos I branch this from the branch where I updated the Design section. So, this PR includes both changes. RIP

Should this be project book?

Should we replace getTempFilePath("ab") to getTempFilePath("pb")?

Should the variable be named pb instead of ab?

Should this be named pb instead of ab?

Should the indentation here and in the method below be 4 spaces from the parent comment?

Is there a reason for adding this? These lines were removed in the previous PR as we removed those fields

Just to confirm, the only time this test will fail is when the description is empty right

Should there be an empty line before the @param tag?

Agreed, maybe we can create a new PR for this after merging all the important features for milestone 1.1.

Should there be an empty line before the @params tag?

Is the requireAllNotNull() method here supposed to check the description as well?

I believe the description parameter is not optional as of now, right?

I think the code here should be rearranged so that it is a little clearer. The modelName variable should be delared after the if (!Name.isValidName(name)) block

Minor typo here

Is there a variation of this test that you have written?

Not sure if this Javadoc adheres to the coding standard

Javadoc here should be StopCommand instead of StartCommand

Should these two checks be extracted out into another method to keep the equals() method here clean?

Should the javadoc here be more descriptive?

Should have an empty line before the @param tag

Should the equals() method below check whether both timers are equal?

By below I mean in the Project.java class, can't really highlight it from here.

Javadoc comment needs to be updated to include timer

Why not just use the otherProject variable here?

There should be an extra line before @params tag and a description for what is returned after the @return tag

Should include an empty line before the @params tag

Can I just check what the reason for changing this was?

I think the commands here can be highlighted once again. For example

/home brings the user to home dashboard

Should we replace these images with @khoodehui 's mockups? At least the ones that are ready

If I'm not mistaken, all existing tags will be removed and only the tag normal will be left. Should we mention this?

Should we separate format and examples into two columns?

Can replace this with @khoodehui 's mockup as well

Should these sentences end with a fullstop

Should there be a big space here?

This is something minor but I feel that it might be simpler to just do

Objects.hash(model, weeklyTotalTimePerProjectStatistic, Arrays.hashCode(statistics)).

Small issue but can you just change ProjectBook to addressbook here because the issue comes from there

I agree with Farrell. I think it might be better to keep it in deadline.

Do you think this method will be used elsewhere in the future? If it is, it might be a good idea to move it over to StringUtil.java

I think the javadoc for this method should be updated to reflect the new name

Should this go under seedu.momentum.commons.core.Messages?

Should these 3 variables just be declared directly since their values aren't passed into the constructor?

Should we implement a compareTo method in Date.java?

Incomplete header here

I think we should have compareTo methods in the Date and Time classes and use them here instead

I'm not sure if there's a cleaner way to do this. What do the rest think?

This part is related to the comment on Project.java

I think you can extract the common string variables that you have reused in this section and make them private static variables. For example, ascending, descending, alphabetical, deadline, created date

You might want to make these public static variables instead. It's used quite a fair bit in tests and it'll be better if they all refer to one variable

Might want to replace the alpha (and other keywords in other classes) with the public static variables I recommended in SortCommandParser.java

Just checking, what's the expected behaviour when there is a preamble?

For example, sort hello type/alpha order/dsc

Is Hello referring to Dana?

As discussed, description will be implemented as an optional parameter instead. A new PR will be created for this issue.

But one thing to consider is that the entry that you are working on might disappear.

Let's say your filtered list only has one entry. If you edit that entry and it the project doesn't match the predicate anymore, the list will not be empty. This might be a little weird from a UX perspective.

I'm not sure whether we should fix this. What do the rest think?

as of v1.2 there is no feature that requires the generation of reports

interacting with GUI with a mouse* ?

Again, no reports yet

include date and time

This is not in v1.2

Don't edit the tutorial

Parameter name not changed

Good

uses '@' symbol

Comment: 32nd not 32rd

Comment needs to be updated

Looks like you forgot to change these comments as well

Comment should be day greater than 31 instead

Is it supposed to be date or Date, previously it was Phone not phone

KIV the prefix because this includes date and time

Perhaps it should be named modelDateTime

Missed this out

I personally feel that date and time should be separate, e.g. 01-01-2020 1200, we can discuss this in the team meeting tonight

Should probably be on separate lines

Should be named something more meaningful like status or taskStatus

Shall discuss whether these fields should be optional in the team meeting later tonight

Should be DATE_TIME

does this prefix make sense or do we need to revise it since its date + time now, maybe it should be due: for example

What is the purpose of this design wise? Is this to act as a null value without throwing NPE?

The rationale behind using java String#trim on Phone was to remove leading and trailing whitespaces. When considering the user's dateTime input do we need to consider white spaces inside the string as well? For e.g. "01-01-2020 1200" vs "01-01-2020 1200" if we are not going to trim it then perhaps we need to consider adding an exception for this and add the corresponding unit test.

Remove this

rename this

rename the date

why did you change this?

can change to complete or incomplete

has a state of incomplete

state of incomplete

May need to capitalise the first letter so that the UI is standerdized

integers*

separated*

Why is done not capitalised?

Do we need to use String builder or is efficiency not important? @BobbyZhouZijian

What does this return if the arg is empty @dearvae

do not add all the white spaces

no space needed here

why are there so many empty lines

what about status

Value of status* - this makes it easier for the user to determine what is wrong with their input if there are multiple attributes in a find command

Remove space

remove this space

why do you need to specify "which is null" when the attributes are the default values?

why cant the default desc be an empty string?

is it necessary to add an extra boolean when there was nothing wrong with the prev implementation?

added extension

These are in addremark.md not actual code, not sure if it needs to be changed

same reply as above

ok undid changes in these documents, please review again

not in this PR

changed

done

changes reverted

this method is to list out the message constraints, in order to have a nice grammatically correct message the last type of task in this String should not contain a comma after it

e.g. Acceptable types of tasks are: A, B, C. instead of Acceptable types of tasks are: A, B, C, .

excellent suggestion, it works as well and is more concise

LOL i thought i deleted, it was for debugging 😃

yes need, good spot

Does not LGTM. Please include markdown for important commands or things to note of. Thanks.

Please include your portfolio under team/GabriellaTeh.md

Resolved merge conflicts and created a new pull request from a different branch

Hi Zijian, I conducted some boundary value analysis and found that it works as intended for the positive test cases but when i put in find status: it does not throw any error, it says 0 tasks listed, following equivalence partitioning i shall stop further tests

A few problems I found:

find status: XXX where XXX is an invalid input, returns 0 tasks found as well

Error message displayed should state that status can only be of 2 values: complete and incomplete.

find date:01-01-202 is also accepted and the date 01-01-2020 matches it, should this be considered an incorrect input

Can you change this to docs/UserGuide.md

Should we remove this *{More to be added}* line?

Can I ask what is gradeDist? Is it grade distribution?

Can I check why we are checking if other is instanceof Name? We should only check if other is also a Location right

Another instance here. I think should be other instanceof Location right?

Should we use Address Class for Task as well? I am unclear if there is a difference between Location and Address class class haha

Just curious, why did you remove the (String) typecasting?

Need to fill in return value here

Can I check, what is the difference between setModule and setModules? They are for different use cases?

Should ass throws ModuleNotFoundException, DuplicateModuleException to the method declaration right? Same for several other methods.

Just thinking. Shoudl we change this TrackItManager? Or TrackIt? haha. If it's too troublesome to change then nevermind.

Ok then we just leave it first. If need be we will let the others add in these methods when they implement further

Maybe we should add throws NullPointerException in the method declaration? Or remove that line in comments.

Can delete the @return here as well, or add the return value

Is this method supposed to be empty?

Can I check why this is removed? Are we leaving it to later to implement?

Why is @Override removed? The getTaskList method is from ReadOnlyTrackIter so we should keep the @Override right?

Is this the final PR for concrete classes? If yes we should re-enable checkStyle

Can remove this comment

Same. Can remove this comment

Here too. Remove comment

Remove comment

Should MESSAGE_USAGE be L list: sample? Maybe change to another word like CS2100 to make it clearer?

Remove Comment. Maybe change MESSAGE_USAGE to have a clearer keyword instead of sample

Should be There is no module matched to the given module code. Missing the to.

Maybe can add an example, like in AddContactCommand

Same here. Maybe should add example.

Same here. Maybe add example

Just curious. Is there a need for PREFIX_TYPE when there is already a PREFIX_NAME? OR this is just for clarity when reading code?

Since the function is parseTime, maybe should change Lesson.DATE_MESSAGE_CONSTRAINTS to Lesson.TIME_MESSAGE_CONSTRAINTS? Just a suggestion haha

Yes this sounds better

Should the ParseException be thrown with empty string? No message?

Can remove the 2 lines of whitespace here

Same here

Hmm maybe write the new message on this line then in the following line you can write catch (ParseException pe) { throw pe }

I meant here, lines 17 - 18

Actually I meant here lines 17-18

Maybe change the comment here address book to app or TrackIt

What does this do?

Why do we need this toString method? Maybe change to Code: and editModuleDescriptor: instead of code= and editModuleDescriptor=

Why do we need this? And Maybe change to Name: is this for testing purposes?

maybe can remove the @FXML private Label desc on top too

Hmm I think we should enable it before merging right?

Oh I didnt IntelliJ will autogenerate toString methods. Do you plan on removing this? Or keep it just for testing

Ok, but I think before we submit v1.3 on Friday we should remove this

Is this supposed to be commented out?

Ok I tried to change to this but err java gives me an error: Illegal escape character in String literal

What do you mean by view it by Id. Task doesn't have ad id associated with it haha

Hmm actually I think writing note/ will be very cumbersome, and may confused users because they are used all 1 letter not 1 word

Hmm ok then can I suggest we stick to r/ for remark, I believe note/ is too cumbersome

Hmm I am following the standard comment format. I think better to keep it this way for now

Ok. I suggest for now we leave it as is. Since Lesson and Task have a date component, we can standardise once both have been merged in and refactor it to be one of the 'commons'. Then that will be cleaner. Maybe leave for v1.3

I think that will require some refactoring. I suggest I create an issue for it and we settle in v1.3

Yes but apart from checking not null, we must also check if the fields fit the specific requirements, which differs for each requirement. Maybe we can look into it, but probably for v1.3

There is no description class. Description is stored as a string thats why I used String

There is no Weightage class. Weightage is stored as a double thats why I used Double class.

Yes ok I will change it

I think we can just leave it for now

This is to support the feature that when the user types c/ it will reset the code to null, in other words they can remove the module code. If only have the latter check c/ will throw error

Same as above. I want to distinguish between storing remark as null vs storing it as an empty string. Unless maybe it is better to just store all null as empty string?

Ok I will leave it first then

Hmm ok I shall refactor this

Just finished refactoring. I think we can merge this first then I can create another PR where I rename the files to AddContactCommand? and etc

Also rmb to fix issue brought up by Weihong. criminal lawyer is not alphanumeric.

https://discordapp.com/channels/@me/763052081266950177/763128915186155520

Is it necessary to perform test after check? I believe check already includes test.

https://stackoverflow.com/questions/50104666/gradle-difference-between-test-and-check

Duplicate https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/13#discussion_r492195636

Do glossary terms need to be italicized? May need to standardize.

Can I confirm that this line will be left unchanged? Otherwise LGTM.

Ok, we will review this again towards the end of v1.2.

Can we verify that this workflow runs smoothly on our repo?

Perhaps you can push an equivalent change directly to a non-master branch first, and see what happens to the gh-pages branch.

Ok, as seen from https://github.com/AY2021S1-CS2103T-W16-3/tp/commit/65e48f7a1f38c68e643cb29f8d29e0951f06bc4c the CI is able to build and deploy GitHub Pages properly.

Suggest extracting these changes to their own commit/issue/PR as they are technically not related to the issue at hand.

See above (https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/23#discussion_r495016936)

Minor typo fixes can be left as part of this PR.

Similar to https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/7#pullrequestreview-492595656, Cygwin messes up on CRLF line endings in the scripts. Not a major problem; the hooks will work as long as the scripts are changed to LF line endings.

After discussion, changes can be left in this PR, but should be separated into different commits so that they will show up in the squashed commit upon merge.

These don't look like intentional changes 😕

https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/39#discussion_r495585791 same here

Minor typo:


The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `TransactionListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class.

Indentation still appears to be slightly off here compared to the previous state


            xmlns:fx="http://javafx.com/fxml">

transaction is no longer the parameter name


     * Returns an add expense command string for adding the {@code expense}.

This should be changed as well, my bad!


     * Returns an add income command string for adding the {@code income}.

Perhaps the variable name should be ft instead of ab?

Also I don't see any method signature for withTransaction(String, String). Is this a problem inherited from the original AB3?

Same as above, consider changing ab to ft.


    public static List<Expense> getTypicalExpenses() {

        return getTypicalTransactions().stream()

                .map(TransactionBuilder::new)

                .map(TransactionBuilder::buildExpense)

                .collect(Collectors.toList());

    }



    public static List<Income> getTypicalIncomes() {

        return getTypicalTransactions().stream()

                .map(TransactionBuilder::new)

                .map(TransactionBuilder::buildIncome)

                .collect(Collectors.toList());

    }

Might be possible to further simplify by extracting out the common parts.

Missing a blank line here


            + "When on Expenses tab: Searches all expenses.\n"

Should this be something like a ListOverviewCommand instead, to highlight that it is for the overview tab?

Ok, makes sense.

Perhaps getTypicalFinanceTracker().getExpenseList().size()?

By the way, it doesn't really matter here but the expected value is supposed to be the first argument to assertEquals, and the actual value comes second.

Does this need to be fixed?

I think we should try to avoid newlines mid-sentence?

Would look better italicized IMO

Perhaps this could be a subheading instead?

Same as above, combine with the previous line


#### Workflow changes


    - `ModelManager`: 3 filteredLists for Transactions, Incomes and Expenses respectively, `FinanceTracker`: 1 transactionList **(Yong Ping)**

This hasn't been resolved yet

My previous comment https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/118#discussion_r506540945 was referring to Line 7, not Line 6


1. Download the latest `fine$$e.jar` from [here](https://github.com/AY2021S1-CS2103T-W16-3/tp/releases).


    public static final Comparator<Transaction> TRANSACTION_COMPARATOR = 

            Comparator.comparing((Transaction t) -> t.date).thenComparing(t -> t.title);

I feel like this could be improved somehow, due to the similar logic. I'll try to think of something


     * Sorts the list based on {@code TRANSACTION_COMPARATOR}.

Never mind, I think it should be fine to leave it as it is for now

I think the root cause is that setValue does not perform any validation.

In addition, the raw input value is being used in the CommandResult.

This is also due to the fact that when amounts are being written, it is using BigDecimal::toString(), where perhaps better abstractions could be done.

In addition, the raw BigDecimal value is being used for the UI display, which will cause inconsistencies as the precision (number of decimal places displayed) is not fixed.

Instead of duplicating code from Amount, perhaps you could write this to encapsulate an Amount instead?

This should solve the validation and abstraction issues faced in the other classes.

Uncaught exception when no argument is supplied i.e. set-expense-limit.

This could be handled either here in the parser or within the command execution (as the amount is being validated).

Also, avoid dealing directly with BigDecimal as it will break if we decide to change the underlying data type for Amount. If there's anything you need from the underlying value, just add the functionality to Amount.

This change should be reverted to prevent merge conflicts with #152.

(unless we are merging this one first?)

Fixed

Unsure if the keywords e.g. "transaction", "date", "amount", "expense", "income" should reference the class names.

Note that placeholders johndoe.md and johndoe.png are being removed as they are no longer needed.

It was found that the shell scripts do not produce any output unless problems are detected.

To make the pre-push hook and CI job more useful, the changes in #23 will also modify the scripts to print their status as each check is being run.

Note that while we intend to rename test methods to match the new model, we will leave the test data alone for now and revisit it in a follow-up issue.

https://github.com/AY2021S1-CS2103T-W16-3/tp/pull/39#pullrequestreview-497089729

Update the package names too to ay2021s1-cs2103-w16-3.finesse as discussed.

Edit: My bad, hyphens are illegal characters. How about ay2021s1_cs2103_w16_3.finesse as recommended here?

Recommend doing this in a separate PR. Refactoring the package would generate a large diff and make it difficult to review the model renaming.

Now that #39 has been merged, all that is left is to delete the Address class, which is incidentally one of the CS2103T tP tutorial tasks.

How should we rectify this? Fix the sample command or fix the validation?

Closed with #136

Proposed improvements based on discussion in CS2101:

Add general description of what each tab is for and what the user can expect (including screenshot)
For commands with aliases/general command words, the title can show just the main command and then list below the alias and/or tabs the general command can be used on
Split transaction -> income and expense for edit and delete commands. This is because the user guide should be based on features available to the user, instead of what commands have been implemented behind the scenes.
Glossary to tell the user (or potential user/PE tester) what a transaction/income/expense represents in the real world, and what the data fields (title, amount, date category) are for.

i agree with jun da, i think changes to different parts of the project should be done in different branches. this is for clarity and ease of finding. might be a bit strange to see a branch merge for both ug and actual code.

for consistency across the entire codebase, i think it'll be better if you have your documentation written like this:


/**

 * Returns a trimmed predicateField. If...

 */

this documentation should be changed too!

there are 2 grammatical errors here - should be "an" instead of "a" and "its" instead of "it's".

also, can you change this reference from address book to Athena?

should be "an" instead of "a" event.

could be wrapped in an Optional instead (since you're doing so below anyway)

consider adding the NoSuchElementException thrown to the method signature

this should be spaced out to three lines

nope, just a personal preference.

do you have an example?

noted. i mentioned this because Parser.parse (and all its implementations) contain an unchecked exception in it's method signature.

this should be changed to match the new parsing structure, and a COMMAND_TYPE field should be added.

this is not implemented yet. perhaps it should be made a bit clearer (with a comment in the code maybe)?

this currently leads to bugs; if i put an index of 3, it'll still return the DESCRIPTION_COMPARATOR. i think you should have individual cases for each comparator, and then throw a ParseException in the default line.

although i think it would be better to have the detection of invalid inputs handled in SortEventCommandParser.parse.

yeah so i think the default branch in here should throw something like an IllegalArgumentException (for us to see, since this branch should never be reached), and the one in SortEventCommandParser.parse should throw a ParseException (for the user to see, if they input an invalid number).

"combines the" repeated twice

i think another punctuation mark would be better - maybe:

"Returns true if the tag is valid - that is, it has at least..."

i think our documentation is done in present tense, so using "cannot be found" would be more consistent than "could not be found". also, since "tags that could not be found" is repeated twice, maybe just rephrasing the entire sentence would be preferable, so something like:

"For tags that cannot be found, the string will reflect that by prepending the appropriate message."

slightly awkward; maybe use firstly/secondly/lastly?

new tagging sounds a bit weird, but this could be me. could you elaborate on what you mean?

tagTree should be enclosed in {@code } for consistency.

did you mean set of persons?

slight inconsistency; first line of documentation says the set returned falls under the given tag and all its sub-tags, but this line says or.

perhaps both these sentences could be combined into one.

i think "given" instead of "if" sounds better.

lacking capitalisation; also i think it should be personToCopy rather than persontocopy.

i think you meant "When relationships...".

i think using "which" instead of "whose" is more appropriate.

perhaps "cyclic dependencies"?

i think you should either connect both sentences with a comma (i would prefer this) or write "Returns false otherwise." in the second.

HashMaps?

Copies*

should these have documentation?

i don't think union is a verb.

who's jackson

should this be capitalised? actually should there be standardisation in how json is referred to? some documentation refer to it as JSON and some as Json.

gotcha.

makes sense.

hmm okay, i'll keep this in mind.

hmm, interestingly this is also something that i had issues with. i avoided using AddressBookParser.COMMAND_TYPE as i did not want to create further cyclic dependencies (AddContactCommandParser -> AddContactCommand -> AddressBookParser -> AddContactCommandParser).

a plausible solution would to be to create an enumeration to only store command words/types and for all command classes to reference that instead, so the test cases can remain untouched.

agreed. i will change these when the above conversation has been resolved.

the implementation would be to create two enumerations - CommandWord and CommandType - and have AddressBookParser and the Command classes refer to the enumeration instead. this accomplishes two things:

resolves the aforementioned cyclic dependencies.
test cases can remain as is, since they currently refer to each individual Command class' word/type.

i think there is merit in having the test cases remain in their current classes as they are intended to test certain classes.

My suggestion was actually to not have this at all.

hmm, what would you propose then?

Use cases to be compartmentalised by individual member.

Introduction not added, reopened

Resolves #82 and #83.

We have elected to update the UG for two reasons:

Consistency - some of the event methods end with an s while others do not. While this was intended to represent the plurality of some of the returns, this can be confusing for users unfamiliar with Athena. Additionally, to standardise methods between contacts and events, we should use the similarly worded commands for both. Since list is already implemented as a contact feature, we'll stick to listEvent.
Convenience - the documentation of listEvent in the UG is incorrect to begin with. Instead of having to correct both the method and the UG (to listEvents), we instead change only the UG.

I will update the UG by tomorrow to fix these inconsistencies.

I suspect it is possible to store this information in a file that already exists in the codebase, as changes to the GUI are saved through different sessions. It is likely that the same file can be used to store this information.

For clarity, this is unlikely to require large-scale changes across the codebase, as existing classes can be used. Instead, the parser will be changed to support the new command structure.

Turns out it's just a macOS quirk. Perhaps this will be implemented in the future, when there are other forms of state saving required.

Looks good to me. I'm just wondering how the TagManager class helps to keep track of the participants (persons) of a particular event without implementing necessary changes in Calendar class or respective events class?

i don't think it's supposed to. this class is just a means to implement better Tag management-related features. the intermediary between contact- and event-functionalities have yet to be implemented.

i think we can give the user the option to capitalise their Tags and use regex to ignore case sensitivity in our searches.

i see your point, but i think the best solution is just to include a way for them to edit their tags after they've been created. as a user, i would not like having to be forced into using a certain case (be it upper or lower), as different cases can add nuance to the tags.

Enumerations added (see conversation with @chan-j-d above for more details).

fixes for this will be rolled out when the new GUI is done.

lgtm - good job!

i will implement this alongside #118.

closed and split into #129 and #130.

in adding these test cases I had to add a few other classes - EventBuilder, EventUtil and EditEventDescriptorBuilder. you may find these classes helpful in constructing your own test cases.

Just a small grammar error. I think it should be students' and not student's?

Maybe it will be nice to change tutees to students? Since we are using students at all other places.

Perhaps it will be better to remove contact since users can edit tags as well. And tags may not be contact information.

Perhaps it will be great to include the format here as well?


**List Students in Class** | `list students /by [n/CLASS_NAME] [m/MODULE_CODE]`<br> e.g., `list students /by n/Tutorial T10 m/CS2013T`

I think you forgot to change the example?


**List Students in a Class** | `list-students c/INDEX`<br> e.g., `list-students c/3`

Nice! 👍

I like this. But i think we need to update the examples in user guide since users don't have to type @ now

Should there be a space before comma?

I don't think there should be address?


        // Keywords match telegram and email, but does not match name

        predicate = new NameContainsKeywordsPredicate(Arrays.asList("12345", "alice@email.com"));


     * Returns an {@code TutorsPet} with all the typical students.

Good catch!

I think this should change to AddModuleClassCommand?


     * Parses the given {@code String} of arguments in the context of the AddModuleClassCommand

     * and returns an AddModuleClassCommand object for execution.

Is it possible to change Node to Label?


     * Creates a {@code Label} with the given {@code Tag} details.

     */

    public Label createTag(Tag tag) {

Or alternatively change the Label in JavaDoc to Node?

I think there is a missing space.


    -fx-background-color: derive(#7392b7, 10%);

Is it An UI or a UI ?

Not sure if we should use An UI.

Is there an extra semicolon?

Great job for finding so many missing full stops in comments! 👍

There is an extra space.


    <!-- Checks that every class declaration is followed by an empty line. -->

I just realized that we forgot to write javadoc for getModuleClassList().

Perhaps this should change to different objects ?


        // different objects -> returns false

Perhaps can add in a test for multiple student indexes/class indexes?

Perhaps this should start with capital letter?


        // Calls #setStyleToDefault() whenever there is a change to the text of the command box.

Perhaps it will be better to rename key to student?

Perhaps it will be better to add a so that it is more consistent? (Add a class, add a student etc)


| UC17        | Add a lesson                          |

| UC18        | Edit a lesson                         |

| UC19        | Delete a lesson                       |

Perhaps it will be better to add underscore in between?


| **Add Lesson**                    | `add-lesson c/CLASS_INDEX d/DAY st/START_TIME et/END_TIME v/VENUE r/NO_OF_TIMES` <br> e.g., `add-lesson c/1 d/MONDAY st/8.00AM et/10.00AM v/COM1 #01-01 r/13`               |


     * Returns a deep copied {@code AttendanceRecord}.

Perhaps it will be better to use class since we are using class in user guide?


            + ": Deletes the lesson in a specific class identified by the "

            + "index number used in the displayed class list and lesson list respectively.\n"

Perhaps it will be better to use student manager since the app is about managing students?


 * Adds a lesson to the student manager.

Might be better to use student manager here as well


    public static final String MESSAGE_USAGE = COMMAND_WORD + ": Adds a lesson to the student manager. "


        // add lesson to moduleClass


     * Returns an add lesson command string for adding the {@code lesson}.

Should we replace it with tutorspet?


   1. Run the `tutorspet.Main` and try a few commands.

I think you missed out this line


   e.g. `tutorspet.commons.StringUtilTest`

Perhaps we should keep the storage?


   e.g. `tutorspet.storage.StorageManagerTest`

Perhaps keep tutorspet.model here? Similarly for the CollectionUtil below


import tutorspet.model.Model;

I think this should be click only?

Perhaps it will be good if we can also explain the functions of the other 2 tabs here (File and Help)?


If you would like to change Tutor's Pet theme, click on the **Theme** tab at the top of the screen. There are

Would it be better to add view?


| **View Statistics**                    | `stats c\CLASS_INDEX s\STUDENT_INDEX`<br> e.g., `stats c\1 s\1`

Might be good to mention the week here as well


* Your `CS2103T Tutorial` lesson in week 10 has just ended and you would like to give participation scores to the students. You

I think affects sounds a bit weird to me. Would this be better?


3. The command execution calls static methods from the `ModuleClassUtil` and `LessonUtil` classes.

Should we put the two terms into glossary? Since they appear in quite a number of places

I think it should be display-venue?


#### Display venue : `display-venue`

Perhaps it will be better to change to Display Statistics so that it is consistent with the summary table on top?


#### Display Statistics : `stats`

Perhaps can change to targetWeek


                deleteAttendanceFromModuleClass(moduleClass, lessonIndex, targetWeek, student);


* One of your students, `Bernice`, has swapped `CS2103T Tutorial` slots and you no longer teach her.

Perhaps it will be good to also mention that Bernice is the second student on the list?


* You made an error while entering the `CS2103T Tutorial` lesson. It should be `Tuesday` and not `Thursday`. You type the command `edit-lesson c\1 l\1 d\Tuesday` and press <kbd>Enter</kbd>.

The meaning of CLASS_INDEX and LESSON_INDEX are explained in the glossary. Perhaps we don't need to explain here again?

agree with this

No particular reason. I am thinking of changing to 52 since there are 52 weeks in a year. Any suggestions for the number?

The end time of the original lesson was 10am, so the start time cannot be set to 2pm. If not I will get a lesson starting at 10 and ending at 2

Yep works on mine too

Maybe the patients should be caps (for standardisation)

I think there is a double spacing between Nuudle and shows

Would delete an appointment be clearer?

Would mark an appointment be clearer?

I think appointments here should be singular?

Maybe it will be better to use the specified appointment?

Seeing that appointment is dependent on the patient, should it be clear all appointment entries instead? What do you think?

I think this should be person or nurse instead

Should AssignLoaderBuilder be DateTimeLoaderBuilder instead?

Because there is no AssignLoader object.

Should there be a closing square bracket?

The boolean isAll seems to be unused.

Maybe instead of using a boolean can consider using PREDICATE_SHOW_ALL_APPOINTMENTS in Model.java then there is no change in the implementation

Lemme know what you think about this! 😄

I think that he handled this under NuudleParser but I think it would be better to do the argument checking in this file instead?

Maybe can try doing the isEmpty check before tokenize?

Maybe can rephrase this to Mark the specified appointment as done or Mark the appointment specified by the date and time as done (more specific version).

Lemme know what you think! 😄

I am not really sure if we should create an appointment without a patient for checking purpose. I made a PR to remove the optional field of Patient so an appointment cannot be made without a Patient (see #90)

Maybe for the filter in line 60, can change it to check if an appointment has the same date and time? (hasDate and hasTime) Do you think this works?

It seems wrong to use a nested class in AssignCommand for non-assign related command.

Should we abstract out the DateTimeLoader into a class on its own? Maybe this can be addressed in future PRs.

editedPatient should be editedAppointment instead.

For this can just add throw new AssertionError("This method should not be called."); similar to above

The check should probably be !target.startAtSameTime(editedAppointment) && hasOverlaps(editedAppointment) instead. (If the edited version is different from the target, make sure that there is no overlap with the rest of the appointment.)

I think that the else { part can also be removed so that the happy path is made more prominent. 😄

This should still be AddressBook?

Should it be Exiting Nuudle instead

Should it be Nuudle instead?

I think Updates all appointments with the given {@code Patient target} with the given {@code editedPatient} would be better as it implies that multiple appointments will be updated.

I think this is correct.

I believe that the check is if target and editedAppointment does not overlap, check to ensure that the editedAppointment does not overlap with any other appointments.

If the target and editedAppointment do overlap, you are sure that there will be no problem adding the editedAppointment as it can safely replace the target.

Actually for simplicity, we can also consider this: call remove on target, then call add on editedAppointment. If it throws OverlappingAppointmentException, then we add back target

Yes. It will still throw an exception.

Good effort on updating the user guide! Thanks for correcting the cancel and view documentation too! 👍

Just a comment: Should we include a constraint on the date and time not being in the past for cancel and done? It's not implemented currently, but I guess we can add it in the next milestone.

I think that the DATE and TIME should be DATE and TIME instead? Same for the documentation for cancel.

I agree with Wanlin actually, I think that it should be ParseException instead. Although IllegalValueException is the parent class, we expect parseIndex to only throw ParseException and if it throws anything else we know that this is unexpected behaviour that we should fix.

I think this can be removed as it's not used in the program?

I think remark should be added here too for the requireAllNonNull

For now, the only possible constraint I can think of is the word length, otherwise, a user can add a whole paragraph to a remark. What do you think?

Ohh I was comparing it with the other command parsers and they were using ParseException. So shd be ok to change it to ParseException

Yep this looks much better! 👍 But is it abit long? Maybe can shorten the last part to refer to help instead?

Should be a {@code Remark} here

Hahaa nice effort! 👍

Do you think it is better if we include the index directly in the tests instead of here?

Because currently it seems a bit inconsistent with the rest.

Not really a big issue tho. Let me know what you think

I think the link should be updated to our group repo

I don't think there is a VersionedPatientBook here

The appointment should not be created when called with lastShownAppointmentList.filter.

toMark.markAsDone should call the markAsDone method in toMark:Appointment which in turns call the constructor of doneAppointment

The link here should also be updated?

The phrasing seems a bit off.

Would it be better if we phrase it as The 'DURATION' is measured in minutes and will be defaulted to 60 minutes if omitted?

Do add on if the phrasing can be improved further. 👍

Yes I agree with Wanlin, isPresent() would be better. The user can change to a specific date, time or duration without changing the rest.

I think that !(appointmentToEdit.startAtSameTime(editedAppointment) && model.hasAppointment(editedAppointment)) would be a better form of checking.

This checks if the 2 appointments are "equal" first before checking if the edited appointment has any complete overlaps with the other existing appointments

Remember to edit this part 👍

The logic for setting appointments can be handled in UniqueAppointmentList and this part can be edited to catching OverlappingAppointmentException and throwing the relevant CommandException.

Oh yeah. I missed that out. Thanks 👍

Oh I forgot to change it to INDEX. Thanks for spotting it 👍

Hmmm, do you think if something like that will be good? See

Oh I missed that out! I'll update it to "hour". Thanks 👍

Ohh yeah. I have updated this on my side. Thanks for spotting it 👍

Agreed 👍

I think this is auto-correct on my part! It should have a tab right?

I have edited this on my side. 👍

Edited! Thanks for spotting it! 👍

Patient details refers to basic information such as phone number, email, address, etc

Same as #18

Will implement together with #31

Addressed in #95

Is this similar to #7?

Implemented as tag during the creation of patient with add

Will be solved by #21

Chaining of multiple commands. Unlikely to do for current iteration

Nuudle app is developed with typing preference in mind

Similar to #12

See commit and workflow for sample workflow run

Should this be Hall-y instead of AddressBook? Also, should it be hall admin (according to the use cases) instead of hall leader? Similarly for the rest of the terms below.

Should it be 'enters' instead?

Hmm seems like there was an issue with Git. Could you keep the original line under 'Saving the Data'?

Also, could you update the command summary at the bottom of the UG as well?

Should it be just 'in Hall-y', instead of 'in the Hall-y'?

Should it be resident instead of person?

Should this be a resident instead of a person?

Nice! @schoolex can refer to this for #37 when implementing the CLISyntax.

Should this be a series of instructions instead of a tip?

i.e. something like the edit command in the UG:

GENDER: must be either M or F
ROOM_NUMBER: must be &gtBlock>_&gtRoom Number>

Should there be a space after the commas?

Should it be 'listing all residents' instead?

A very minor nit, but is there an additional linespace between the previous method and this method?

Should GenderType type be a private variable as stated by the coding standards?

Minor nit again 😟 . Is there an additional linespace between this if block and the previous one?

Should the getEditPersonDescriptorDetails() in the file be updated also?

Should this be GENDER_DESC_BOB instead?

Should the "M" be GENDER_DESC_BOB instead?

Would you consider adding a similar test for invalid gender as well?

Would you consider updating the MESSAGE_USAGE in this class as well?

Should the constructor of this class be updated as well?

Minor typo here in the comments.

I think we need this for the Jekyll project site.

Should we standardise and use application instead of app since it is a formal document?

Should be it designers instead of designer?

Should it be document instead of documented?

Should there be an additional fullstop?

It doesn't really matter, but you can consider using event.getDescription().description as well.

Okay for this is fine for now, but maybe you can check if the editedEvent and target events are unique before setting them into the list? Else you might get duplicates within the UniqueEventList.

Nice!

Is there a typo in the javadocs? editedEvent instead of editedPerson

Hmm... this is okay, but do test with very weird user inputs - like if they insert spaces anywhere.

E.g. assign 6 1, assign 6 1, etc.

Can consider doing a nullcheck on model too, similar to DeleteCommand.

Neat! Can consider checking that residentIndex > 0 and eventIndex > 0 as well (either here or somewhere else).

Hmm could you explain the TODO?

Based on my understanding, ModelManager updates the filteredPersonList during a add command because the user may have keyed in find X, followed by add Y - so the UI needs to reset back to the full view by updating the predicate.

Can you do it in both? So its similar to UniquePersonList.java#setPerson

Okay, try to keep this in mind while testing 😄

Is this method named wrongly?

Neat! You can consider going further with this type of test case: e.g. "1 1" (2 spaces between each 1).

Sorry this should be target.isSameEvent(editedEvent) - they're slightly different.

Should it be execute_assignResident_success() instead?

Oh ya! I'm so sorry, I was wrong.

Hmm... These 2 steps are not very clear.

My guess is that ListGroupCommand#execute gets the filteredpersonlist, then iterates through it and gets a set of student groups?

Hmm... should we still keep the alternatives since there is only one design here?

Should it be ......is called...and returns...?

Sorry could you change this to make it clearer?


4. The `ListGroupCommand` calls `ListGroupCommand#execute()` *which* retrieves the list of all residents by calling `Model#getFilteredPersonList()`.

5. The `ListGroupCommand#execute()` iterates *through* the list...

Hmm the old link generates a badge though. Using /actions/ doesn't generate a badge, but a link instead...

Ohh I see. Sorry I misunderstood that.

Okay! I updated it. Currently it's just dummy data. We should probably have a source of truth somewhere in the code to validate if the block numbers and room numbers are all valid (I'm thinking somewhere in preferences.json might be good).

Okay done. Thanks!

Okay, I have added a field to manage the list of attendees tot the Event class.

I didn't add the way to add students to the list yet - this is still a dummy implementation and there might be some design considerations you can make for associating persons to events (e.g. unmodifiable lists, etc).

Might need change this implementation to also compare the attendees list

Similarly, not sure if this hash will take into account 2 events with same name, description, but different attendeesList (or that it doesn't matter).

We should. Doesn't really make sense to have just the alternatives with no explanation.

Okay! Fixed it after our standardisation - to keep all return arrows.

Good catch! Fixed 😄

Sorry! Fixed.

Seems that requireAllNonNull() checks all items as well. Refer to UniquePersonList.

Oops.

Closing this, since it is part of the tutorial. Will not be merging unless we decide to drop address.

Closing this, since it is part of the tutorial. Will not be merging unless we decide to add Remark.

Need to verify if the tP tracker will still pick this up if the PR is closed. Do reopen if the tP tracker requires the PR to be open for grading.

Closing since AB3 already implements this feature. Do make sure if that the feature works with the updates to #10.

Remove from milestone v1.2. Will consider adding this into milestone v1.3.

Oops I missed this out: could you also update the command summary section for the edit command too?

PR closed as I messed up Git. 😢

Closing this, since it is part of the tutorial. Will not be merging unless we decide to add Remark.

Not sure why the badge doesn't load when it's first loaded, but after refreshing, it loads? 😕

Closing. Has been completed.

Closing for now since the tP tracker says there are no references left.

DG might still have some (since the explanation of the code still needs to use AddressBook*.java), but that's fine.

Nice, thanks! 😄

EDIT: was part of #91.

EDIT: was part of #91 as well.

I think you should keep "Developer".

I checked again, and I think you missed out the find sales history feature under sales tracking.

I agree.

I think that this should be specified as a sub feature under list, so as to distinguish between all ingredients and a single ingredient.

Perhaps this archive employees contact details section should be grouped with the other employee contact details features?

I think this page will be continually updated, so we should include what we have done to the project so far - which would be the documentation section.

For the ingredient levels, it would be good and clearer to state the unit of measurement. You could add this to the description or edit the examples to show this is the case.

We are missing Feature 4.3 Find the sales history data based on date documentation.

Remove the bullet points in this section to standardise the description field for the features. Instead of starting with a noun, start with a verb (once again to standardise across the UG). Eg. Set the level ...

Since it's just one argument, requireNonNull(targetIndex) will do.

I think we should keep both. They will both be Phone objects, but with different prefixes.

Perhaps you can use requireAllNonNull(...) instead.

Should this be using .equals method instead to do the check?

You are missing empty lines in between the methods.

IngredientList should not be under AddressBook, as AddressBook should only be in charge of contact details.

Mismatched javadoc?

As mentioned earlier, functions and features relating to ingredients tracking should be abstracted out to its own classes (instead of being in AddressBook).

I assume this has yet to be implemented?

Incorrect test case? Should these be all throwing assertion errors instead? They should not be called as it is a default model stub that have all of the methods failing.

Should target be non null too?

Requires change to fit ArchiveList

Missing public attribute? Applies for all the other tests.

Unnecessary white space?

Is this an extra space?

Command is an abstract class, no super constructor is needed.

I think that perhaps naming the boolean isReset is better, so that there isn't a double negative. This is just a grammar comment.

No need to use String.format if there is nothing to format.

I think that they should be on the same line.

I see,, then it makes sense to use isNotAlreadyReset.

I think it is better to be placed on the same line to standardise with the other case statements.

Should be Unarchives as the command is singular

Is this an extra line?

Grammar: It is equivalent to *the person being archived) OR (having archived the person).

Could be better phrased as: "A Person whose archive status is true"

Similar to the above comment

Perhaps it should be views because a command is singular.

Can be combined by using requireAllNonNull, however, this is also fine.

Extra line

This can be placed in one line

spelling: should be archive

The command is s-update. Additional there should not be a colon after the command word.

extra fullstop

Oh, I am referring to the description. It should be "views a single ingredient ... ", since the command word is singular

I think it is better to keep it in one line, so that it is standardised with the other case statements.

LGTM

I don't think this line need to add UC2?

Might be better to change it to:

McGymmy shows a list of food in the database.

List of Food that user has added works too

LGTM

Just curious, what does this affect for the main page?

It kinda looks like a link to the repo like github.com/se-edu/addressbook-level3 and github.com/AY2021S1-CS2103T-W17-3/tp

Yes need the space after the ##

Might want to change this to a constant?

Like VALID_NAME_AMY, similar to the one u did in edit command test

Ookie in that case LTGM

I think we should use this.class.getName() instead and put it in the Macronutrient class and use it for each of the food items?

Might be able to clear up quite a few of the other assertions and methods mentioned below in Macronutrient

https://www.tutorialspoint.com/java/lang/class_getname.htm

Might not need this if we can get the nutrient type using the method mentioned in Carbohydrates.

This link might need to be changed in the future

Might be better to remove for now?

Might be better to put it into a method rather than just declaring

Can use @Before to initialise the fridge to reduce the complexity of layering the different test cases on top of one another (This might help if we decide to change/add more test cases in the future)

@Before

public void beforeEachTestMethod() {

    System.out.println("Invoked before each test method");

}

Might wanna remove this whitespace for consistency

Might be able to use CommandTestUtil here to reduce code duplication.

Can compare the tags after the CommandTestUtil.assertCommandSuccess

I think there is alr a similar method in the current version

I think the standard for 2103 uses 8 spaces instead iirc. Same for Food.toString method

I think the test convention for other test cases are like getCalories_isCorrect or smth like that x.x

^^ Same comment as Joey

Might be better to abstract this.protein to getProtein(), same for carbs and fats

Might want to change like the names to something more food-related >&gt

Sorry I meant case insensitive >&gt

Oo yea true. rip idk what i was thinking when i vetted x.x

Might be better to use regex to check if it is of the correct format first rather than having an empty catch clause?

Nice color 😄

Hmm true.

But I rmb hearing somewhere in 2103 that empty catch clause is bad thou.

Hmm ookie

Might want to add some test for editing the date in the future

Can add some assertions here regarding calling the function when it is unable to undo

Is this for it keeping the same filter after the edit of the food?

I think it should be throw DataConversionException here?

I think its the same thing here?

and here?

I see

This line will need to change to MacroList

This line too

This line will need to change to fit Macro Context

Maybe remove the initialiazation and just assign macro = source.getAsList().stream().map(JsonAdaptedMacro::new).collect(Collectors.toList())

Hmm I see

I think its good to add an assertion if the food to be removed does not exist as checking for existence should occur before actually removing the food.

Something along this line instead?


var predicate = filteredFoodItems.getPredicate();

newList = listOfFoodSomewhere.stream.filter((x) -> !predicate.check(food)).collect(Collectors.toList());

setMcGymmy(new McGymmy(newList));

I think you haven saved this file to the .png format yet

I think it is to confirm that the code is working when we run it with assertions.

The if statement below is to make sure that there are no errors in case we miss some paths / did not run with assertions

the filtered list is implemented in Model so I think it will be better to implement in model instead of in Fridge.

Can be a possible future optimization

I think it will be better to put the food item as a Parameter instead of optional?

If all of them are optional the user can just get away with using just find unless there is some form of a check to ensure not all of them are empty

Oh ok, I see. I think we can mention that in the DG and no changes will have to be made.

What do you mean by this?

Ookie Thanks

Simplified similar to how Kamil did it

Tags and Addr not implemented as they will be removed by the end of the iteration

Will make this a not draft after I add some tests or something maybe

The code is mostly formatting text to be printed so I don't think unit tests will benefit it much

Might need to change the logger message in ui/HelpWindow.java and remove the function that shows the help screen

Error in Merging Master Branch Closing PR

https://stackoverflow.com/questions/27567846/how-can-i-check-out-a-github-pull-request-with-git

For pulling it into your local Repo

Something similar already exists in ModelManager.

Refer to ModelManager

Duplicated Feature

Merged to Update Developer Guide Branch

Adding extra stack to store predicate for filtering

bug found

bug found

What is the bug

The one where the TypicalFoods was mutated in between the test on the Mac CI

Joey Found and mentioned in the Whatsapp Grp earlier today

I think you pattern did not match our command. Here is my suggestion:

(?&gttype>[A-Z]\s+)?(?&gtcommandWord>\S+)(?&gtarguments>.*)

Maybe we rename this class to Contact now?

Ahh I see, just add another \ before each of the current

I think this should be kept simple, for example: "Adds a contact to the app" . This applies to all of your messages

You're missing the "T " prefix before the COMMAND_WORD here and at the example a few lines below too 😄 This applies to all 5 of your commands

I think the example for time here should have hour:minute as well, we'll support that too

As discussed, I think this should return a task's to string, and view it by Id! We won't have any find command

After coding I think that all of these "notes" like things should be called "notes" with a prefix of "note/", and this field is purely optional. What do you think?

for my iP I have written quite a nice date parser here, I think you can adapt it to this part (and add more supported format too)

this comment here is quite obvious right? I think can just write it as "Parses a Remark"

As I have commented on ViewTaskCommand, this should be modified accordingly

Ah my bad, by index

yeah I know, but like I want to create a special prefix for the note-like stuff, for users to throw anything they want into it

Okay then maybe you create an issue for that?

okay sure!

okay!

the Task.Type is missing here 😄

Missing Tash.Type here too!

should we merge Location into Remark now?

Not Email right?

Just wondering, is there any better way than manually checking 5 fields to see if they are null or not? I think there is a requireNotNull method as well right?

not String right? desc has type of String but for the message it should be Description

Not Double.class.getSimpleName() right? It should be Weightage

Okay sure

Yeah but for the message you can't output like "missing a double", better to just replace it by "Weightage" (a String) since the Double.class.getName() is basically get the name of that class

Hmm should we edit the module by index? or should it be index?

We haven't agreed on whether a task must be associated with a module or not right?

Should we merge location into remark now?

Should it be to switch to the module tab now?

love this simplicity 👍

actually it will like expand the task (view in greater details)

Now I think we should rename it to view

for this, is it better if we have the type like lec (for lecture), tut(for tutorial)?

"the length of the Lesson list" sounds a little unnatural, maybe "the number of lessons"?

not of that type right? now we changed to deleting by index already

same here, maybe "the number of lessons"?

why do you need to check Task.isValidString here? I thought only the latter check is necessary?

I think the remark doesn't need any kind of validity checking right?

Hmmm I think this is fine but later on probably I will abstract this thing to the "common" module

LOL It just crossed my mind, I think this is better as isDone (shorter and more "grammatically" correct haha)

hey this should be isComplete haha. A trick to faster change the name of a variable is to use Find and Replace haha

I think this method can be named like "flipDoneStatus", I think it will be a more intuitive name right?

yeah store it as an empty string is better

My bad😢

True

Hmm I have removed this class already?

Ah okay not yet, my bad

Can you take a look at my new PR?

If that PR is good then can merge it first, so that there won't be too many commits in a PR

Okay I forgot. Actually the original code doesn't explain the returned result too (maybe too obvious?)

Yeah, since originally there were setContact and setContacts as well

the original code base doesn't have that throw as well. What do you think? (Honestly I haven't read about when we should state that this method will throw something and when we can just omit it). Anyway, will read it later on after I finish developing these 3 classes

I think we should best leave it as TrackIter (short,concise name). LOL It took me 1,5 hour to rename address book to TrackIter 😂 (And still there are a lot of leftovers)

Fixed in the latest commit

Okay lemme fix it now

When I thought on how to handle the program's logic, I found out that putting lessons and tasks in Module will make it way harder to find/delete tasks & lessons. Instead, I think that we just keep lessons and tasks in separate lists and everytime we need to find lessons or tasks of a module, we can just do a O(n) search. This will make the program's logic much simpler and less prone to errors

Yes. Is just a more detailed type of exception, so it doesn't need any implementation

It will be fixed in the next PR!

Wow I think this is a bug happend when I'm copying things

fixed!

Ah okay okay let's enable it

@simonteozw Maybe you approve this PR first then I make another PR? I just run the code formatter and it changed like 80 files

Actually I wrote the message for this exception already, but then deleted it because the exception caught on the very next line. Should I comment on why I leave that message empty or just write a message in it?

done!

this the auto toString method generated by IntelliJ. It will be used for testing only so I guess it's best to stick to the default format

for testing only

Sure

There is a warning that the operator (like + for string concatenation) must be on a new line, but I haven't found a way to make IntelliJ auto-format for that, and it's really minor so I will just disable it for now

Hmm because I haven't been able to get the IntelliJ to conform to this rule, and this is very minor (it's just the position of the operator) so I think it's best to disable it for now (if not forever)

No it's a good thing to keep, why need to remove right?

Yes, because as we have discussed this will be a "bonus" feature. I just leave it there so that later on we remember

Yes, I realised it too but I forgot to raise it up during yesterday's meeting! Will send Simon another PR.

Ah I resolved it already! Forgot to close this issue

@simonteozw can you review this commit then merge it for me so that the next PR won't be so huge

Actually "commons" in the name of one of the current module too! (seedu.address.commons)

Ah that checkstyle, I think it can be disabled for now, later on when I merge the later pull request I can enable it back again! Actually we can do cherry-pick there but I haven't had time to properly learn cherry-pick

@nguyendqminh can you take a look at my message above and provide me the deadline that you will resolve this? Thank you!

@simonteozw Hey can you take another look? If it's good then you can approve it so that I can make the final PR for Lessons

@nguyendqminh Hi, any updates on this?

@nguyendqminh Can you push your commits to the PR so that the team can know your progress? Thank you!

@simonteozw Hey. I think this PR is quite simple but I think it's best to have you do a quick review of it! Thank you!

@simonteozw this can be closed now right?

Closing #109

I think that to match prefix, the e.g. would be sth like list l/people, list /stats. Please check on this.

Might want to refer to this as Virus Tracker instead of AddressBook.

Might consider changing to 'Clears all entries from Virus Tracker' to match description in line 42.

It appears that you have added some new functionality here regarding some statistics. Can these be used already?

Considering the nature of this test, it might be best that the method updateFilteredLocationList is completely removed from the working program since it is not expected to be called.

Additionally, on this aspect, I realised that updateFilteredLocationList is a method newly added to Model and ModelManager. Considering that, may I check why is the method added if it is not intended to be called as seen from this test?

I understand now. Thank you for the clarification.

To keep the code clean, I feel that this line should either be uncommented or removed.

Ids are abstracted away from the user. Users should not be aware of Ids, and thus should not be given the opportunity to change the id of a person. I feel that thus editpersondescriptor should not have an id field and id is automatically retrieved from the person that is being edited.

Some additional tests can be conducted in this class. Such as tests for adding unidentifiable locations and tests for setting location lists which dont fulfill the identifiable property. You may refer to #118 UniqueLocationListTest for reference.

One more test was missed.

To abide by SLAP principle, consider abstracting out different parts into a separate methoda in the same class.

For e.g. line 50 to 62 can be abstracted into a separate method

The "..." seems to imply that the command can accept multiple personids. Is that intended?

You have made tests that dealt with the edge cases. It would be good to have additional tests that prove the success of the command. In this case, it would be giving an infected person and confirming that the generated results are the expected results.

Could this perhaps be shifted to info handler class? This can help to keep calculation and information handling methods consolidated in one place.

This code is quite long. May I suggest extracting part of it into another method? This is a suggestion in accordance to single line of abstraction.

You have added tests capturing failing conditions. May I suggest tests that confirm success conditions as well?

Is this possibly a spelling error? Form or From?

Perhaps some documentation or name changing could be done? Its hard for me to directly understand the significance between 60 percent and the visits chosen.

This test feels like it might be more appropriate elsewhere. This is a class for tests involving location as itself. Perhaps this test might belong to a info handler or for a class that directly implements this.

Perhaps these methods could be shifted to info handler class? This can help to consolidate all information handling methods to one class.

Suggest using a comment block instead of multiple single line comments.

A comment block looks like this.

some comment

more comments

Suggest putting both comments in 1 line rather than having multiple single line comments.

This method seems very similar to the above method getTypicalLocations. I feel that since both methods are used in test cases, naming this method getLocationsForTest doesnt differentiate the purpose of the 2 methods. Perhaps naming it as getUnorderedTypicalLocations() would be better?

This method seems very similar to the above method getTypicalLocationBook. I feel that since both methods are used in test cases, naming this method getTypicalLocationBookForTest doesnt differentiate the purpose of the 2 methods. Perhaps naming it as getUnorderedTypicalLocationBook() would be better?

identical visits here, resulting in error.

I think that there is no need to create a separate exception for wrong date. Instead, parseException should be used.

According to the code in Parser class, any exceptions or mistakes in the input is returned in a ParseException. In this case, we can save on a class whose implementation is identical to ParseException.

I think this message can be replaced with the MESSAGE_INVALID_DATE_FORMAT constant from Messages.java.

With the comments above, this can be implemented as a single line instead.

date = ParserUtil.parseDate(argMultimap.getValue(PREFIX_DATE).get());

Sure. Understood

Instead of having this, suggest importing the message from Messages.java

please revert back to a single line

Sorry, please ignore this.

done by direct editing of file.

Please refer to it as index rather than id. Reminder that ID is a concept that is hidden from users.

Suggest to replace with the assertThrow from Command utils

Suggest to replace with AssertThrow from command utils

This test is repeated and ought to be deleted.

Repeated tests are detected here.

Please change this to index instead of id. Only index number is exposed to the user.

Suggest replacing with an existing method inside command utils that handles commands. The method name is AssertCommandSuccess()

Spelling error is intentional for the invalid person.

Have added additional assertions.

Have changed the method name

Thanks for the catch! I have updated it.

This copy of valid visit is hard coded, by using the visit builder class. The hard coded values are retrieved using the getOneBased method. Valid visit has no direct reference to filtered visit at all.

The gist of this test is that my model's filtered lists for person and location currently store only 1 location with id 3 and 1 person with id 4. This is done using the showLocationAtIndex, showPersonAtIndex methods above. Im giving the model input using index 1 and index 1 for person and location, because the list user sees contains only 1 element. After processing however, I am expecting the visit to point to ids 3 and 4 respectively. This is done by comparing the final visit from the visit list with the expected visit created using valid visit.

isnt this repeated with #19?

isnt this repeated with #18?

Pull Request Approval:

Before approving any pull requests, please ensure the following is done.

Eyeballing the code for any possible logic or other errors. This is also to familiarise yourself with implementation of the system.
Pull the pull request down into a local branch and give the features a test run. This is to check whether it actually works since eyeballing code may not be fool proof in ensuring functionality.

In addition, you might want to update the details of the pull request if it does indeed include some functionality involving the daily statistics. This is on the assumption that it is included.

Pull request was merged using Admin powers without going through 2 approvals.

However, noted that I would have given approval after the recent commits, so no harm done. Please be careful in the future though.

Thanks for the review. I have improved the Pull Request according to your comments.

Suggest to merge visit id fix PR first #136 and see if any of the tests crash for this particular PR.

If none crash, I will automatically give my approval for merging this.

Shall be closed as participation has already been counted and PR is not relevant for VirusTracker

Completed by #126

Hi everyone, please help run a few test runs with the application.

Pull from this branch into a local branch and run a few methods that you created for the application. This can help confirm that the application has not bugged out or lost any functionality during refactoring.

This merge does not implement a WrongDateFormatException.

Instead it throws a ParseException that represents a wrong date format.

Resolved by #161

We noted that this implementation presents the following bug where an update to a person/location name does not correspondingly update the name of the person in the visit. This will be resolved in a future update.

Due to the wide ranging impact that this change could be bring, this is deemed as a prerequisite issue that should be resolved as soon as possible before other pull requests.

This pull request is ready for merging.

While all effort has been made not to regress VirusTracker in this PR, because ID is used widely across all aspects of the VirusTracker, it is recommended that all teammates check through the tests and functionality in detail for any breaking of code or bugs.

Users will be expected to prepend their own data with prefixes before importing data. This could be something we can look into for further enhancements.

Rationale for using prefixes: To avoid autoformatting which may lead to effects like removing leading zeros. Adding prefixes ensures that a CSV that was exported can be imported without changes to another program.

Maybe you can use an empty line instead of using &gtbr>

There is an extra &gtbr> at the end, which will increase the gap between this line and the Acknowledgement. Is it intended?

Should there be an extra white line here?

Maybe there shouldn't be a &gt here?

I think you broke some of my parts. You can review this markdown file again to find out more.

Before

After

I have night mode enabled so it is more obvious.

There's still something wrong here.

Did you change the package name to fileAddress?

Shouldn't it still be tag?

Maybe can replace person with tag in the message as well.

Should the person package be renamed to tag?

This may not work later because of the FileAddress field. Maybe add a //Todo here for reminder.

JsonAdaptedTag was used to store tags for person. For now shouldn't it be deprecated since we do not have that functionality?

Is it really person details?

Is this println for debugging?

Should this be "Tags list contains duplicate tag(s)."?

Is this for debugging?

This may not work. But for now it's okay.

For now it's okay. This will be looked at again by the Logic team.

Are these tests no longer working?

Extra spaces here.

Are these 3 variables no longer independent Ui parts?

// Independent Ui parts residing in this Ui container

Maybe the name of the variables here could be changed?

Maybe "valid" file path?

Could this be changed to a more sensible tag name?

Should there be empty lines here?

"Person" should be predicate here?

Method name should be test_keywordMissing_returnsFalse?

This validation regex is for names. Should this be dropped?

Should this class be named ObservableFileList?

The file can be changed to HelloFile.jar?

Displays

managed tag names -> managed tags?

"Renames a tag's name"?

Typo in design?

Absolute path is already ensured in TagCommand, but its still okay to get absolute path again here I think.

I get it now.

This part should not be changed. This are the default tags when HelloFile is launched the first time. We might want to keep this list empty?

Should there be an empty line here?

This edit is not correct? TagCommand do check if the file is present using java.io.File.exists().

What?

Roger that

We need to change all the entities in testUtil.

It's not a typo, it's a real word =)

conform

/kənˈfɔːm/

verb

comply with rules, standards, or laws.

I find that without "\n" the format is very hard to read, so I added them.

That's going to be more readable in my opinion.

Right now the tag command is like this. You cannot distinguish tag name and file address easily.

Ok will change that

I don't think we will be doing manual testing anymore. Moreover, this appendix is for us to read and probably not suitable to be included in DG.

test

Resolve #36

Hi Heinrich, could you make a stub so that we can use it to work on Logic? Thanks.

Yes! I think that will be good.

Looks good. Is it possible to have a toggle for this theme?

You mean something to switch to different themes?

Yup

Cd can change current address.

Format:

cd f/absolute address

cd p/

cd c/child_folder_name

Getter and setters

FindCommand can have t/, d/ or (t/ and d/).

Alternative

cd f/absolute address

cd ../

cd ./

Can't really check the UML..but LGTM!

You can use "view file" at the top right corner to see the markdown file.

small issue maybe it should be example instead of examples?

same issue here

there seem to be some inconsistency here. do you mean JOB_TITLES instead?

do you mean job_title

I think what Shawn said makes sense. It might be better to stick to terms that are already established eg InternshipStatus. If I am not wrong does the status class exist only for Internship? If that is the case, maybe you can consider shifting date to the Internship object instead and as such, there won't be any ambiguity in the naming.

small typo

might want to maintain consistency with other files where you leave a line at line 9 for this class.

there shouldn't be a return

I realized that some javadocs there's full stop while some there aren't.

If most to all parser requires these static final int variables, we could shift it to avoid duplicates. However, I am not sure if it is apt to shift it to an interface. Can consider having a Util class for it.

the parameter should have a space

I am wondering if since the Internship has been categorized into InternshipCliSyntax, perhaps this could be also categorized into ItemCliSyntax, or were u planning to convert this class into that in the future?

hmm i am not sure which "style" we want to stick to but shawn has another way of writing this InternHunter detects an error in the input format . We might want to stick to one way in order for our DG to look cohesive.

should use &gtbr />

should use &gtbr/ >

Would it be weird if it is "viewing" the profile page? To be cohesive to our DG, You must be on the **profile** page ... sounds more cohesive to our precondition

an exception should be only thrown when it is like not within the programmer's control? like missing files or user input. Since it is a controlled environment, using assertion is more apt. It's from oracle java assert.

Small issue, can put /todo for future.

not totally sure how regex works but from the description are you rejecting # and +?

do remember to add in javadocs in the future

do include the @throws.

do remember to add in javadocs in the future

just a suggestion, @line 38-39

from GitHub this line looks quite long, you can consider having

boolean b1 = ...

boolean b2 = ...

if (b1 || b2)

oh, but I think keane/shawn side is allowing the use of those though! it might be confusing for the user ? can either @keanecjy @shawn-nyk confirm this?

@throws missing

InternshipTitle instead

might want to change the variable name for clarity

Internship titles should only ...

might want to change it to INTERNSHIP_TITLE_DISPLAY_NAME

just a minor question but is there a need for this if block? I think we could just shift it into the if-else block. However, if this is a better coding standard, then I think we can stick to this.

oh if this the case, I believe the current code is a better option

I realized for constructors, in our main code, we use Creates, so maybe we could stick to the same javadocs for cohesiveness

Maybe can just remove the InternshipItemUtil class which and just be Provides the string used in ... ? or perhaps A utility class that provides ...

Sorry may I know what's the difference between COMPANY_OUTPUT_NAME and PERIOD_OUTPUT_NAME

could they just be summarized intoCOMPANY_NAME = "Company Name: "

sry whats the difference between space and blank

Dont forget to remove the Sout

We were discussing this previously and we decided that this allows an easier skill matching.

Because the user can key in any type of requirements which can be very long will definitely render the skill matching useless.

Should we stick to how other messages are done, I realised we are missing the Parameters: ...

Might break some test cases message.

I think now we can do model.getFilteredProfileListSize(). Do you mind helping me and shawn change that portion

Same here can help to change to getFilteredApplicationListSize()

Yup, It might be more consistent to change the type to category.

Thanks, @keanecjy will add the missing information. Maybe it might be more apt for us to put it as "what our app manages" under introduction

Yup we could keep it simple currently and once we merge them in the future, we could include those extensions.

perhaps once we merge the similar use cases together, we can include more extensions to it!

hmmm, I am not very sure if it should be an exception instead. I was following the assert from oracle java.


The absence of a default case typically indicates that a programmer believes that one of the cases

will always be executed. The assumption that a particular variable will have one of a small number

of values is an invariant that should be checked with an assertion.

Have fixed the java docs issues, thanks.

I will resolve this conversation since we have concluded it.

True I am not sure about which is a more appropriate wording.

Thanks for the spot, will update it.

Thanks for the clarification Shawn, what I meant as this naming is, Company & Application to have the same Information Width. I will do the relevant changes to make it clearer.

Not very sure how to resolve this portion. Maybe I should a raw type parameterized instead?

yup I think I should change this to setRequirements

yup I think I should change this to setIndustries

yup, I have fixed this

yes, you're right. I will do a work around.

Thanks for the advice, did not know there is such a thing.

resolved in the latest push.

Yes, i agree as well. I will help to reformat the rest of the parser

While trying to reformat, I realized that We would need to know the Type of command in order to get its MESSAGE_USAGE. If we were to shift it to GeneralParserUtil, we would need to determine the Type of command and pass it as a a parameter into the static method in GeneralParserUtil. However, this determining of the type of command is already present in the parse command, as such we might be writing two switch cases. However, if we would want to write only one switch cases, we might have to change how the code would like like.

Also from the way we coded previously, the switch case in the parse method would never go to the default case, we can do an assert false there? (Since the checking is already done in the checkCommandDetailsIsNotBlank)

However, a method that is possible is that we will have to shift that checkCommandDetailsIsNotBlank into each of the cases in the switch method as well as introducing an extra parameter.

'''

public FindCommand parse(String args) throws ParseException {



    String itemType = getItemType(args, FindCommand.MESSAGE_USAGE);

    String commandDetails = getCommandDetails(args);



    isValidItemType(itemType);

    switch (itemType) {

    case COMPANY_ALIAS:

        checkCommandDetailsIsNotBlank(commandDetails, itemType, FindCompanyCommand.MESSAGE_USAGE);

        //return new FindCompanyCommand(commandDetails);

        return null;

    case APPLICATION_ALIAS:

        checkCommandDetailsIsNotBlank(commandDetails, itemType, FindApplicationCommand.MESSAGE_USAGE);

        //return new FindApplicationCommand(commandDetails);

        return null;

    case PROFILE_ALIAS:

        checkCommandDetailsIsNotBlank(commandDetails, itemType, FindProfileCommand.MESSAGE_USAGE);

        //return new FindProfileCommand(commandDetails);

        return null;

    default:

        // Invalid item type

        throw new ParseException(MESSAGE_INVALID_ITEM_TYPE);

    }

}

Sorry, I don't quite get what do you mean as throw the exception with the correct message.

Sorry, I don't quite understand what do you mean about profile item having a general error message 😮

Issue

I reaslied this as well. For commands that are without the letter specifier, like

view me 1

delete me 1

It seems to have this special other error message generator.

And as a result, since find is somewhat the same, I try to extract this duplicated method from view and delete as well.

In comparison to other classes

I realised for the earlier commands like Add, the message is encapsulated inside each of the individual type of add commands instead, because they made used of tokenizer as its checker

While for the later commands like view and delete me, since we dont need to use the tokenizer, it seems like we generated another method for checking instead

Is there anyway we can consolidate this issue. This is linked to the problem Keane and I was discussing in the post above. @AY2021S1-CS2103T-T15-4/developers

So I take that we should format it such that delete, view, find should follow how add, edit does it?

Ah, yes that is true, will make the relevant changes once we get our affirmation regarding the above dicussions

oh this sounds great, will abstract it into messages.java then

yeah i did thought about it, but it feels weird if we have to add in a condition for it LOL for whether to display the extra s. Hmm i think since we are dealing with a 1 vs Infinite amount, it feels like having the s should make sense right O:

hmm, I think since this is a more towards only switch kind of command, I believe I should make a separate message then. Are there any other commands that have the same issue? I believe list and find as well right?

Thanks for the spot

I think I will temporarily put this as %1$d %2$s items found!

LGTM

#87

LGTM

If we are planning to create other classes in replacement of person and address book, I don't think we need to change the Javadoc yet?

#48

#99

Hmm. The dilemma now is that this is just a proof of concept and we may be abstracting common logic down the line and scrapping all these, so overwriting Javadocs now may redundant. The danger is that if the code is kept and the comments are missed in the future. What is the team's opinion on this? @ZoroarkDarkrai @keanecjy @seanjyjy @shawn-nyk

I agree that overwriting Javadocs now may be redundant, especially because our code can change over time up until the final version. At the same time, I also agree that we may miss them in the future, and doing a one-time run-through of all our code at the end may be very tedious and error-prone. As such, how about we do something like: every time we create new bits of code that require Javadocs, or we modify code that already has Javadocs attached to them, we place a standardized comment, such as TODO: Javadocs above the code we need to write/edit Javadocs for? That way we get the syntax highlighting that IntelliJ provides for the TODO keyword, and we can also search for this standardised comment throughout the code base to hone in on where we'll eventually need to write/edit Javadocs when the time comes. Any thoughts on this?

I think this is a great idea what do the rest think?

#104

#100

LGTM good job.

Hi, Fidella I think since you approved these changes I will just merge it in? Need this code currently

LGTM good job.

Can add the todo or javadocs and it is good to merge.

Which file/line are you referring to?

DeleteProfleCommand class and maybe its constructor? incase forget in the future

Will merge this first

LGTM

Besides the point that @keanecjy has raised, I believe it is good to merge after it is resolved.

LGTM

the link seems to be still broken. From the html file side

the link seems to be still broken. From the html file side

Sorry my mistake

LGTM

#25

LGTM

Overall LGTM to merge, just need to fix the image link. Think there is a typo in the png file itself

Just some comments for you to consider, not very sure if it is right or wrong.

For sd execute edit me command, you might want to include what is return in the getProfileList() perhaps.

And for void methods like setItem and setProfileItem i believe the return arrows could be omitted as it doesn't bring any value and it does help to reduce cluttering.

However, if you think that it is fine, then do let me know as it is good to merge already.

LGTM. Good job

LGTM

UC 07 seems to be broken in terms of formatting

I just realised, but just for plausible consideration, should we add-in extension for deleting companies that indicate internships being deleted as well as its application.

Perhaps can add a description saying that this is the constructor?

Should be project book instead of address book.

Same here too as above comment.

Perhaps there should be a whitespace after the slashes?

Yup think it will better to describe that it will construct a new project, just like the javadocs in other classes.

Will it be better to give an example of how the ISO8601 time format looks like in the error message? A user might not know what this format is.

Should have a new line before the param.

Think the persons here should be timers instead.

Should have a new line after the description. Same for the 2 methods above.

Newline after description.

Extra line here should be removed.

Extra asterisk here should be removed.

Newline after description.

Newline before method.

Should we remove all the navigation commands first? Since they are not yet implemented.

Description has been changed to an optional field.

Should both name and description be optional fields here?

I think we can indicate [coming soon] for this.

I'm not sure if this section should be done by @boundtotheearth, since he implemented this and according to the tP instructions, it is recommended that features in the user guide should be written by the person who implemented it.

Similarly, should we remove this first or indicate it as [coming soon]?

Same as above, for Create and Update, some of the fields are/are now optional.

Not sure if it would be better to rename this as 'Editing a project'? It might be more clear that the name of the feature is the same as the command.

I think it should be. Because it doesn't make sense for the user to have to enter something for the name when they are not intending to change it. I think we might have made a mistake when writing this section of the user guide.

So the edit command will be like the addressbook's, where all fields except index are optional, but at least one of the optional fields must be provided.

Same case for **Note:** here as above.

Seems like markdown isn't converting **Note:** over here to bold. I think it's because it's embedded inside HTML. Try using &gtstrong>Note:&gt/strong> instead.

I think the asterisks here are causing Markdown to not format the table correctly.

Newline before param

Newline after description

Code might be easier to understand if parseSortOrder() only returns the argument which the user entered in the command. Then under the variable declaration for isAscending(), do an equal() check to see whether the argument the user provided is equal to ASCENDING_ORDER.

This is so that the nature of the parseSortOrder() method is also consistent with that of the parseSortType() method.

I think we should.

Noticed that you have declared various form of SortCommands as private static final variables in SortCommandTest.java, and they are repeated here. Will it be better to just abstract all of the various SortCommands into a utility class, then have the test classes get the different commands from there.

Accidental capitalisation here

Line before param

Line before throws

Line before param

Should the javadoc for this method and the one above be on just one single line?

Should projects here be changed to trackedItems?

Ok yup I agree with this. Will make the changes.

I feel that it is ok to have this method as well as the hasDescription() method in the Project class, as a Project should be aware of the contents of its own fields and I can directly ask a Project whether it possesses these fields.

However, what you said sounds fine to me too. What do the others think?

This was following the discussion yesterday, there is no view command for profile.

Maybe it will be more consistent to change type to category?

Also, I think this was left out in the issues, but the switch command can be added too

Do you think it is good to be overly specific about the type of error? If so then there are many more extensions to include such as inputting an index that is not a number for example.

I am unsure about this myself but what if there are no items in the list? what kind of interactions can the user and system have? I know your preconditions addresses that but do we have to consider the case where you call edit and there are no items in the list?

Really minor a UI not an UI

Should be an exception instead?

Should be an exception instead since you are not testing an assumption?

Should be an exception instead, since exceptional case

The other JD comments are in the other PR, you can ignore them for now if you want unless you it is finalized

Sure we can have a common package for the fields within model package but for unique fields with own regex, keep them in the feature's package.

Minor nit, should be Sets in the Javadoc

Same thing here. Minor nit, Should be "Sets"

Same thing here -> Sets

Change -> Changes

Same minor nit Set -> Sets

Set->Sets

There are 2 more that require changing below:

Initialized
set

Javadoc comments below as well for set.

Perhaps its more appropriate a throw an exception here since assertions are mainly to check for precondition and post condition of function execution and testing assumptions. This usage fits neither and is more of an exceptional case?

Same issue here ? You are not testing assumption here, exception better?

I think you may be missing a line break here?

The profile command is updated with [t/TITLE] and [d/DESCRIPTORS]...

I think you have have missed out deleting this UC05

Is this supposed to switch the tabs? It doesn't do that at the moment.

okay! I tested on my add and delete commands but it doesn't do anything yet. Is there more to the switching besides setting the model state which I have missed from your implementation? I think you may have to return the multiarg CommandResult as there is a boolean arg to indicate whether to switch ?

You may want to reduce depth of nesting here? I get that you need three loops here maybe if you using streams can help with that? Or 2 other functions that handles each loop and use boolean flags to terminate the final loop?

What happens with the internships don't match? Maybe I am mistaken here but it seems like you just let it pass and create the model out of the unmatching internships instead of an starting an empty list for company and application?

Do you think it would be better to shift this logic (LOC:91>) to this own file,? Main app is starting to become too big?

Maybe it would be more appropriate to include an assertion or throw an exception here if this is not expected to be called since its harder to debug with null?

I have updated the Descriptor class with its own regex, does this affect the storage in anyway?

Is there a reason why this does not return a jsonadapted profile item?

Initializes?

Javadoc could perhaps start with Switches.... depending on

Perhaps you could change it to Represents a class...

Start with sets..

I was wondering if there is a need for a switch statement here? Correct me if I am mistaken, but this just checks if the user provides an string query for to search for? Is the intent of this function for a more tailored error message based on the item type queried? If so why does profile Item have a general error message?

I dont know if you need a fullstop here?

Do you think this should be part of the design component?

@keanecjy maybe you could parse the skill title to [str1, str2, str3] then check if any of the substr matches your requirements? something to that effect

You can ignore this first. The content page can be changed after all the headers are in.

nvm, its good to merge, I have updated the contents page to link to my headers.

Okay, will update!

yes. These did not have preconditions, I'll remove them.

True, I should remove this, I think the only precondition then is that the system is running which is not very meaningful in this case.

Okay will make the change!

sounds good!

Yes, there will be multiple descriptors which can be added similarly to tags.

I think this is the work of IntelliJ auto injecting imports. I will move it.

I was going for a primitive implementation for now, but since the types are fixed, I think enum is good solution too.

I stopped changing this because I was unsure if we need 2 levels of inequality for profile items.

I have not created exceptions yet so this is a placeholder

I didn't change this yet since this was the original file but I suppose like it can be changed now too.

Sounds good! I was thinking of doing so after the other parsers are done since for example the EditParser for the InternshipCommand may want to abstract 3 items (comindex, index ,prefixes)? So it depends on implementation of the parsers first then after which we deal with abstraction for common vars.

Yep, some of initial JD do not have full stops too.

I'll update this! thanks for the catch

@seanjyjy yeah I was thinking you could always type c sharp or cpp for those cases .

@keanecjy Good point, I am ambivalent about this. But could the same be said for Names as well, maybe we can consider a char limit for that?

There were changes in the branch, need to resolve some conflicts! @seanjyjy

I noticed that many of the javadocs used "person" and "address book", should we change it now? or leave it for later?

Hmm. The dilemma now is that this is just a proof of concept and we may be abstracting common logic down the line and scrapping all these, so overwriting Javadocs now may redundant. The danger is that if the code is kept and the comments are missed in the future. What is the team's opinion on this? @ZoroarkDarkrai @keanecjy @seanjyjy @shawn-nyk

Yup I think that there isn't a need to concern about javadocs / comments as of now as they can be easily fixed at any point in time. @orzymandias I stopped editing the List portions as I noticed that there were too much code duplication with your pr. Do we plan to either extend an Item class or use generics for our list?

I agree. I think there is unnecessary duplication for collections, generics is a good idea for collections but one issue is with throwing custom exceptions for different types of items within the generic list. Should we just have DuplicateItemException then something like throw new DuplicateItemException(T.getDuplicateExceptionMsg())?

ecessary duplication for collections, generics is a good idea for collections but one issue is with throwing custom exceptions for different types of items within the generic list. Should we just have DuplicateItemException then something like throw new DuplicateItemException(T.getDuplicateExceptionMsg())?

I don't think this works because we are not able to access methods in java generics. I figured since we all are classifying our classes as Item, we can have an Item interface to contain all the methods similar methods like isSameItem and likewise do throw new DuplicateItemException(item.getItemName())?

Sounds good.

Overall looks great, just some nits to fix.

Just a side question as to would it be confusing as AddCommandParserWrapper is essentially Similiar to DeleteCommandParser, however, they have different naming syntax.

Is this implementation temporary in order to allow ab3 to function properly?

For AddCommandParserWrapper each item has its own set of parsing rules which may require their own individual parsers so the AddCommandParserWrapper is only responsible for funneling the appropriate item prefix to its add parser. The thing about delete command parser is that there is lesser parsing involved except for extracting out the index to be deleted. With the exception of internship which has an additional index required, all the other commands just need the index extracted to be passed to their delete commands. So I am not sure there is a need a wrapper in that case.

As for consistency I think once AddCommandParser can be safely removed, we can rename AddCommandParserWrapper to AddCommandParser.

Just some conflicts to resolve and it will be good to merge.

Can add the todo or javadocs and it is good to merge.

Which file/line are you referring to?

Overall LGTM to merge, just need to fix the image link. Think there is a typo in the png file itself

Thank you, Good catch!

Just some comments for you to consider, not very sure if it is right or wrong.

For sd execute edit me command, you might want to include what is return in the getProfileList() perhaps.

And for void methods like setItem and setProfileItem i believe the return arrows could be omitted as it doesn't bring any value and it does help to reduce cluttering.

However, if you think that it is fine, then do let me know as it is good to merge already.

Thanks for the feedback! I have updated the getProfileList() depiction but I think I will keep the return arrows for the time being since I think the clutter is still ok and I see that Shawn has also used them to indicate that the methods has completed its execution.

LGTM, need to resolve some conflicts

I just realised, but just for plausible consideration, should we add-in extension for deleting companies that indicate internships being deleted as well as its application.

Good point! Not sure how to appropriately frame it and if it should even be an extension of company or part of internship/application. @shawn-nyk @keanecjy What do you guys think?

I think "module" here should be "modules" instead.

"Lists all modules provided by the university"

Unless 'n/' command is taken, I think we should use "n/" instead of "un/", it seems more intuitive for the user to add his/her own name as "name" rather than "username"

Should we allow the user the flexibility of determining start and end date? Isn't it better to only allow the user to specify the academic year, and we will provide the start and end date for the user. I think this would make it more convenient for the user.

Similar concern to my above comment, whether we should use "n" instead, as well as whether we should allow the user to have control over the start and end date semester.

'DAY' has* instead of have. Also, I think it'll be good to capitalize first letter of the days Monday and Sunday:)

Similarly, "WEEK" has*.

Additionally, "Total number of weekS".

If we do decide that user shouldn't be able to select start and end dates, then the total number of weeks will be pre-determined already.

Same grammatical error as above comment

There's an additional 'e' here in "edituseretask"

task ID example given here is not really consistent with the sample command (line 248) which uses "id/usrta001". Additionally, the example command here uses "dy/3", I think it should be "da/3".

I feel that the command could be better named, for example using "edittemplatename" instead. Although its a slightly longer command, however it gives more clarity than "edittemplate" as to what the user is editing. "edittemplate" gives off the impression that I can edit preset user tasks in the task template?

Why is this named "listtasktemplate" instead of "listtemplate" for consistency with the above commands "edittemplate" and "createtemplate"?

Grammatical error:

"total tasks for that day exceeds"

Similar grammatical error for "exceed"

I don't you need "pti/1" in a cleartemplate command.

Grammar: I think it should be "List all the task templates that were created" instead

Is MODULEINDEX here a list index like "3"/"5", or would it be a module code like "CS2103T"?

I think deletetemplate here should have a "tti/TASKTEMPLATEINDEX"

In the e.g given, cleartemplate shouldn't have "pti/1"

I think we are going to omit MyModules from the architecture, we will be using ModuleSchedule instead, so this use case should be View ModuleSchedule instead

Should we follow the three part format for naming of test methods?

Likewise for the naming of the test method

Similarly for the naming of test method

Same here for the naming of test method

With this implementation of the parsing of user input, what happens if the user inputs something like:

addexp ... f/for now no OR addexp ... f/think no.

Although in an actual use scenario this is very unlikely to, or will never happen, but would the parser still allow the creation of the expense object in this scenario?

GrAB3 should be SuperSalon

I think you can add system and actor here and for all other use cases

I think we can change the method to saveClientManager

The comments here should be for the BreakdownExpenseCommand class instead of the constructor?

I think this implementation still allows for intYear to be negative? For example range.isValidIntValue(-999) will still return true. Since the java.time.Year class has a MAX_VALUE of +999,999,999 and MIN_VALUE of -999,999,999.

Should we fix the VALID_YEAR to be 2020? Would this still work when I'm using this after the year 2020?

I think your method naming here should be breakdownRevenue instead of breakdownExpenses

Same here for method naming

Should use logging instead of the SOUT?

Similarly for this SOUT

The additional && appointmentDate.equals(other.appointmentDate) check is not required right since isClashing is only called if appointmentDate.equals(otherAppointment.appointmentDate) in line 123

Maybe using "exists in Homerce" is sufficient instead of "homerce book"?

Yes I think it happened during the refactoring from Addressbook to Homerce

Moving forward, I think it'll be good to have an empty state screen for the user

Okay thanks! I'll change it

Okay, thanks for this, I've updated the response messages accordingly!

Thanks for the comments @khoongwk @yanlynnnnn , I have made the changes as requested!

Thanks for the comments @khoongwk @yanlynnnnn, I have made the changes as requested!

Possible to follow Pattern BASIC_COMMAND_FORMAT check used in AddressBookParser?

Reason why ModeParser did not use Pattern is because the commands that ModeParser will parse does not follow the regular format of commands with all the Prefixes.

Might need to take out UserPrefsStorage from Person Package.

AddressBookStorage seems to specific to the Person Model, what do you think?

Can remove all isMeetingCommand methods

Implemented only for LogicMode because need to know whether to switch mode in MainWindow, whereas it is certain that LogicMeeting will be handling a user input if the current mode is Meeting

Will need to accept Contacts Model eventually also so that index of contact can be referenced

For cleaner implementation, possible to use Pattern found in AddressBookParser?

split method used in ModeParser because none of the mode commands use prefixes.

May be good to just add userPrefs (just reference to same object)

Eventually will have a FilteredList&gtMeeting> filteredMeetings ?

Good to take out UserPrefsStorage from person package

Will StorageMeeting be extending from AddressBookStorage?

Generalise this so that deliverables and contacts can also use the 'parseDescription'

Add a note or TODO that this is to be renamed and Description is to be deprecated

OptionalDescription.isValidDescription

This may be intended as a String but could be resolved by generalised method as described above

Same as above

Could consider adding another static method / overloaded constructor that takes in a String so that we don't need to call Optional.of so many times

From, To and Deadline will implement this so Message might need to be more general

I was thinking whether we could just generate the valueString on the go instead of having an additional attribute

Would optional DateTime be supported?

is person card currently using this?

more valid inputs:

-29th February for leap years

more invalid inputs:

-with seconds

vary the years to see how far back / into the future can be accepted / rejected

feel free to think of more test cases

probably an exception? since its invalid user input not problems with our code

requireNonNull

where will IllegalArgumentException be thrown from?

assuming all caught IllegalArgumentException is related to INCORRECT_FROM_AND_TO_ORDER

could try directly using isValidFromAndTo instead

"### [Proposed] Autosort feature"

Remove "#### Description" to standardize

"#### Proposed Implementation"

"#### Design consideration:"

"##### Aspect: How autosorting executes"

Alternative 1 (current choice): ...

email is a compulsory field (phone is an optional field)

Standardize headings - we are probably only sticking to Implementation and Design Consideration

Not sure whether we should standardize not to give e.g.s

standardize leaving empty line

standardize capitalization

DateTimes or dateTimes?

Test case or Testcase

item = Contact?

Would it be all three .json files?

I think this is for the initial initialisation of the Ui (to contain the Contacts List as of now). Can be changed later on to show dashboard

Yes, maybe we can discuss the ordering because the one in the User Guide may be outdated

Updated in README.md

Rescope to just initial implementation of optional fields

Not for merge.

Might need to change the URL for the badge!

Oops! I think the benefit for this is wrong!

Also, I was wondering if we should combine the benefits stated in potential users and use the combined version for this user story?

Apart from this, everything LGTM!

Just a minor issue but perhaps this @return should be removed as well!

Oops minor typo here!

I think this should be removed as well!

Perhaps it might be better to change this to a more warehouse-like-name to avoid any potential confusion! Wondering if we need to change the variable name as well?

Do we also need to change the variable name here as well?

Here too!

Oops traces of supplier here!

This part here as well!

This should be AddProductCommand!

I think this message could be clearer! Perhaps something along the lines of "Tag names should contain only 1 word"!

Perhaps this could be "Adds a product to a supplier in the CLI-nic app"!

Just wondering if this violates the law of Demeter?

Not too sure if this is on the same line! But if it is, perhaps the concatenation might not be needed here!

Can I clarify what is the remark book??

Oops! Lines 76 and 78 are swapped!

Not too sure if this is still relevant!

If the above comment is relevant!

Perhaps the else clause could be removed here as well!

Perhaps the clause can be removed here as well to make it more prominent!

Minor typo here! Should swap "the" and "from"!

Perhaps we should try to make the explanation consistent for both suppliers and warehouses??

I think the message should be "not stored / contained in warehouse"!

Just wondering if this line is extraneous?

I think it should be {@Index} instead of @code targetIndex! I believe they used the class instead of the argument name!

If we are using the class name instead of the argument name, then this part needs to be changed as well!

Perhaps we could just return the function without the else clause here!

This @code too if we are using class name!

This too!

Do we have tests for invalid index when deleting products??

Ahh oops! I was wondering if it would be possible to make the explanation for the examples in line 159 and 161 consistent? In line 159, it says "of the list of warehouse" and then in line 161 it says "from list of suppliers". Would it be possible to use the same format for both??

Ahh okok! Thanks for clarifying 😃

Ahh ok! Thanks for the update!!

Oops typo here!

Hmm the example above doesn't really show the t/TAG! Might be a little confusing!

Yes I used the same reasoning as edit! But then again, this was why we decided to go with prefix for the find command as well!

I suspect last argument might be a little confusing because users might think it is the very last argument at the end of the command!

I think all the arguments, except INDEX, should be optional here

Likewise for here

should be .getMaxQuantity().get().toString()

because .getMaxQuantity() returns Optional&gtQuantity>

would isQuantityPresent be a better name?

shouldn't this be replaced by if (!(other instanceof RemoveCommand)) instead

Sorry I think I misunderstood what you asked last time haha. But do you think there should be some indication if stock goes above 100% as well

I believe you should also try a test case with a non RemoveCommand object. I believe the current equals method doesn't handle this and will throw a ClassCastException

apart from this small issue, it LGTM for me!

Could be more SLAP like

return hasNextCommand() && isWithinLengthLimit();

Is this abstraction really necessary?

I'm a little confused as to what the role of hasReturnedCurrentCommandBefore is. Could you add a comment to the code explaining a little what is going on

Fair enough

Looks good. LGTM!. Really good job on figuring out the logic

Should change the name of this variable to better reflect its purpose

actually it just occured to me after merging that this name is also not appropriate LOL. It should be more like dateTimeFooter or something, because you aren't saving anything

In the else condition, you should return quantity1 - quantity2

i.e. when percentage is same, or when there is no percentage, then the item with lesser quantity is higher up

Do we want a separate (from getFilteredItemList()) method here? Why not let sorting be done within getFilteredItemList()

why not return this in getFilteredItemList()

Not an issue, just that this is the first time I have seen o as a variable name 😆

should it be && or ||

I don't think the "Sorted" part is accurate here. The old name updateFilteredItemList sounds more appropriate

Sorry this one very nitpicky, but if you're changing the "o's", can you change this one too

and this one

the original is correct (i.e. prefers typing to mouse interactions)

user executeS. (missing s)


OneShelf is capable of storing many items and pending deliveries. 

Therefore, it is of utmost importance to have the ability to find items

and deliveries based on different fields. There could also be many similar items and 

this will definitely aid the user in find them quickly. <br>


and `TAGS` for items using `find-i`. Similarly, for deliveries, it is also possible

Good idea to mention that!

lexicographically (typo)

"Comprises" is misleading. You could say "is implemented by InventoryModelManager and DeliveryModelManager", but frankly, it's not necessary to add that line here. The first sentence sounds enough since this is just an overview

Having the d, or some label there, might be usefeul, to show the command being passed back to the front. For instance, right now you do use the "command" label on one of the return arrows, which essentially represents the "d" here

There isn't a "ModelManager" class from what I remember. It should be "DeliveryModel".

this is the thing I'm referring to. Over here you use the label "command", but it's not 100% clear where that came from, which is why I think you should replace all the d's you removed with this "command" label

This shouldn't be removed, it's the constructor for DeleteCommandParser

"in finding them" or "to find them" either is fine

this one is my fault I apologise

I have refactored maxQuantity to use Optionals instead of using "0" now

oh didn't realise that happened, must have been automatic

thanks for catching that! yes it should be DeliveryListCard

have fixed it

Yeah sounds like a good idea!

"will NOT match" so original should be fine

Yes actually I copied most of it from the find-i command, and I was also confused as to what was being said here. I believe it's trying to say that if you have an item called chicken and one called CHICKEN, then both will be returned (although this is no longer applicable to us). I'll change it to a more appropriate example

What do you mean

I know we're changing this, but to answer this, I didn't think it necessary to check deliveryModel since it wasn't being used

Good point. Will add it

ok let me try

Makes sense, I shall change it

issue with this is that it becomes hard to make a canRedo() method without adding another pointer, which makes things messy. I think our array limit will never be set beyond a few 1000 so it's not an issue (and if it is ever changed, the code can be refactored then)

Manual testing shows that it works as expected when the limit is 1 or 2

oh sheez for some reason my github didn't show all your comments

ok so for the static variable, I luckily saw the issue too and just fixed it. as for the capacity != size part, yeah my bad haha still rusty from 2040 times will add it in

ok you can check it out now!

thanks! shall start work on test cases then

Done!

Yeah it does, but this is NFR so you're stating that the user should have this. Like it's the assumptions you're making about the system the program will run on

Budget is part of NFR because it is a constraint on the project. (Although from a quick google search, it is a bit debated, but the top answer here says it is

Right yea that definitely needs to be removed. thanks for pointing out!

I believe it already has been added by Xing Yu in the next paragraph

OH, because one of my tasks for the weeks was to show help in the result display on start up that's why I edited that. Should I revert it back?

Or maybe can ask @wengfaing to make a separate message to display for help on start up and then later change it to show that instead

Yes, good catch

Ah I feel like we'll never run out of these mistakes haha

I've made the relevant changes!

Ah I understand your concern, and yes the rephrasing is good. Will add it in

Can but they are different things so I don't see the harm in separating them

ok sure

Physical inventory referring to the actual restaurant's inventory. meaning it won't actually clear all the items out or anything. Just to emphasize that this is a productivity tool, and not an actual product that physically manages your inventory

well you're not wrong about the googling 😆 . Yeap I'll just remove it

I'll just remove it as well since it's quite nonsense

@Wincenttjoi I thought just need make pull request only for the tutorial. Everyone else's pull requests I see also have conflicts

Haha no worries

Currently tests are failing, because @xnoobftw will be working on them, so merge this first (if all else looks good) even though the CI build is failing

@xnoobftw done! CI is passing now.

By the way, the conflicts came because of my PR which just got merged, so just keep that in mind haha don't throw everything out

@Wincenttjoi ah yes that does make more sense, thanks!

@wengfaing how do you want to divide this task

@AY2021S1-CS2103T-T12-1/developers do you want the Delivery section and Items section to be of equal width, or the current width they have right now

Currently it looks like this

For the colouring, is it easy to implement colouring to be conditional (red vs green if stock falls below 20%)? If its a huge task we can create a separate task.

Yes that is very doable

Further improvement:

Low priority: I didn't do the GUI for help toolbar on top to open up the 2 different help windows since the app is meant for CLI primarily. But feel free to connect them if you want 😃

I'll check it out

@Wincenttjoi I've made the changes you requested, plus changed the whole structure of the DeliveryList GUI to match that of the ItemList. (Tonnes of headache cuz debugging GUI is super hard).

I also wrote the basic code in MainWindow.java for initialising the values into the DeliveryList on starting the app, with currently an empty ObservableList&gtDelivery> being initialised temporarily. The Delivery class I wrote is also currently just a stub with no functionality.

Disagree. Different restaurants may use different kinds of metrics and having metrics follow enums we may not cover all cases. In such cases edit command would suffice to correct the error

agreed

@AY2021S1-CS2103T-T12-1/developers do remember to pull branch-delivery to your local repo before working on it if you're working on this branch

Could someone jog my memory on what is required for this again, apart from just renaming the command syntax and repackaging the files

Yeah. It becomes a bigger issue when searching by phone number or address in the deliveries

Yes that's possible. Is there anything else you think we should do as well. I'm thinking delivery order as well.

Fixes #116

Just want to check if you're bothered by the naming? Because sometimes I get confused that Item is actually referring to only Inventory. Sometimes I would think of Inventory item vs Delivery item (Item is the umbrella term for the different types)

Any thoughts for this? If you're okay with I'll see what I can refactor in next PR too

I think our understanding is that Item refers solely to inventory item

Lol I already added an issue for this. I'll just delete my issue

Metric should not be allowed to change in an add command on an existing item
Appropriate error message for when a user tries to do so

@xnoobftw yea sure!

Refer 8daa9e6

@Wincenttjoi I'm having some issues with the test cases (they work individually but don't work when the whole test suite is run. I've been googling but still am not sure where the issue is), don't think they'll be done any time soon.

Maybe PR first so that the rest of development can work on top of it (for instance the new delivery commands will need to take this into consideration now)

Edit: don't merge this yet

Can accidentally do my DG also

Sure, will check it out

Oh I only purged for "addressbook" earlier but didn't think about "address" in general. Thanks for pointing that out

Agreed. The user might not know the exact start and end dates of his semester, and we also do not need to take into account the user entering invalid start and end dates if we provide them for the user instead.

AY20/21 Sem missing a '1'

*Duration is measured in hours and must not exceed 24 hours

Same rephrasing as above comment

*has

Can omit the second line if we are providing them with the start and end dates?

Will listpresettasks be more intuitive since it will be a list of preset tasks?

Remove a Module and all its Module Tasks from the Module Schedule

*load all its Module Tasks

If its "CS2103T", maybe we can change it to MODULECODE

Do we have a method to list all the task templates or will the GUI take care of that?

Use either remove or delete

Agreed

*listmymodules

List all the modules that the user has selected.

tasks*

Maybe can change to List all tasks instead of Listing a Task Schedule? As schedule itself refers to a list of tasks

Think you might have added an extra '.' at the end!

Should it be 'parameters' instead of 'parameter'?

Should SERVICE_CODE be added here?

maybe can replace 'additional' with another word, or just write 'displays a success message'?

*updates

*requests

*deletes

*match

*shows a, *match

*an

*displays

*an

*At least one service exists in the service list

Does it guarantee an empty service list as well?

maybe can change description to details?

*service

*GrAB3 shows the list of expenses sorted in ascending order

Should be 'expense' instead of 'revenue' here

I'm currently using the Tag Class provided by AB3 which does not handle white space, will handle it subsequently if it is consistent with the other features using the same Tag Class.

Noted, I have changed it from a character to a String. Thanks for pointing out!

Shouldn't example usage (below) be updated to include the IC field as well?

Shouldn't a javadoc comment be included similar to the other models?

Shouldn't there be a multiple ICs test?

Shouldn't there be a missing IC prefix test?

Shouldn't there be an invalid IC test?

Shouldn't parse_oneFieldSpecified_success and parse_multipleRepeatedFields_acceptsLast also have tests for IC?

Shouldn't there be tests for null and invalid IC?

Shouldn't it be BloodType instead of weight?

If you refer to the javadoc for the other methods, shouldn't it be @code String BloodType and @code bloodType?

Shouldn't it be bloodtype instead of weight?

Shouldn't there be a description of the parameter?

Should it be Constructor instead of constructor?

Javadoc comment does not follow the coding standards

Shouldn't it be there be a space before Blood type: ?

Shouldn't it be BloodType.MESSAGE_CONSTRAINTS instead of Weight.MESSAGE_CONSTRAINTS?

Shouldn't it be blood type instead of weight?

Shouldn't all the missing field prefix test also include VALID_BLOOD_TYPE_BOB so that the tests would be consistent with each other?

Shouldn't it be blood type instead of weight?

Shouldn't method header comments start with a verb?

The class header comment is not consistent with the class header comment like Phone or Email

Shouldn't all these "N/A" be abstracted out?

Why not use the stringEmail, stringAddress... methods?

OPTIONAL_FIELD_EMPTY_MESSAGE and "N/A" has been used over multiple classes. Maybe they can all use the same constant in one of the classes?

Same as before, why not use the stringEmail, stringAddress... methods?

Is it necessary to use nested Optional?

You can use the or method so that the get*Field* method does not have to return a nested optional

You could maybe use the ifPresent method

Why not use the stringEmail, stringAddress... methods?

why not use the stringEmail, stringAddress... methods?

I think you forgot to update this part

Shouldn't it be getStringIc instead of getStringIC?

TableView is missing its generic type

Shouldn't it be TableColumn&gtPatient, String> instead?

Shouldn't the imports be written explicitly?

Perhaps it would be good if we insert our website here.

Perhaps we could keep keep this so we can change it individually

Perhaps we could keep keep this so we can change it in future

Perhaps we should keep the product name consistent, to Insurance4Insurance, I4I

Perhaps we can add a "Coming soon." here

Perhaps this could be "Adds a client to I4I."

Perhaps this could be Format: add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [o/NOTE] [t/TAG]…

Perhaps this could be

Examples:

add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01
add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal o/This client is new.

Perhaps this could be Lists the entire list of clients in I4I.

For now, for v1.2, I think we would try to minimise the amount of fields to delete, so we would add in NOTE and keep the rest. However, this may change in v1.3/1.4, so we can update the UG then.

We can add back the "Tip" for tag if you are okay with the above change.

Perhaps we can format INDEX to INDEX.

Perhaps we can edit to Example: list followed by delete 2 deletes the 2nd person in I4I.

Perhaps we can add a Coming soon here

If you are okay with above edits to add, perhaps we can change to this:

Add | add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [o/NOTE] [t/TAG]… &gtbr> e.g., add n/Betsy Crowe e/betsycrowe@example.com a/Newgate Prison p/1234567 o/This client is new. t/friend t/criminal

Perhaps we can add in help as well, since we are implementing in v1.2

Help | help

Perhaps we can add this back, since we are implementing help in v1.2

But we would need to update the image to https://ay2021s1-cs2103-t16-2.github.io/tp/UserGuide.html

Perhaps we should change this to

Wraps all data at the client-list level

Would it be better if we have multiple tags and 1 note? i.e. the ... comes after tag instead

Perhaps this can be updatedNote?

Perhaps the message could be "Notes can take any values, and it should not be blank"

Perhaps this can be package seedu.address.model.person;

Perhaps seedu.address.model.note.Note can be simplified to Note

Perhaps we can return noteName

Perhaps this could be " "?

Perhaps we don't need to add an invalid tag here

Perhaps we could add back the space here String ...

Perhaps we should add back the space here?

Perhaps this should be 8 spaces relative to line 22? But not sure why the original AB3 passed checkstyle

Similar concept for the rest of the lines in this file

Alright got it

If I didn't understand your question wrongly, the withoutNote() is meant to add in a null for BENSON, who originally has a note

Reopening this issue as PR was accidentally merged

Note that this PR was merged by accident, reopening issue and creating another (similar) PR

Resolves #6

Ensure that source should be &gt= 50 characters.

Update URL and image in UG

address
email
phone


Edits an existing tag in StonksBook to the specified tag name. All entries previously associated with this tag will be updated to associated with the updated tag.

I think we can remove the here


* All contacts that have been previously associated with this tag will be updated automatically to be associated with the updated tag.

Should we mention friends here? I think it may be better if you just mention that it updates the name of the first tag (as per tag list)

Same comment for here (about whether to mention friends)

Maybe we should consider switching to an ordered list if we're going to make reference to other points

Think you're missing a Use case ends. here and in some other portions below as well

Can this be indented to be the same level as 2a? Likewise for the remaining use cases


2. StonksBook adds the provided tag.


| `* * *`  | efficient salesman                | list all sales of a contact                                   | see all sales made to a contact easily                                                        |

I think here we're assuming that contacts are sorted before sales right? Should we add a comment stating this assumption?

Can we write this section into an if-else block with the above? Then we can also remove some duplicate code

Hmm, is associations a bit hard to understand here? Would it be better to be more verbose here and say something like Note that all items that have been previously associated with this tag will be updated automatically to be associated with the updated tag. as per the user guide?

P.S. May also need to update the user guide: it currently says contacts when it's supposed to be generic right?

Same feedback here as in DeleteCommand

Is this comment still relevant? If I'm not wrong it refers to the tags stored in the persons/sales right?

Javadocs here is inaccurate

Would it be better to initialise a new HashSet with the original tags, remove the target, then add the editedTag in order to prevent arrowhead-style code? Same can be done for the removeContactTag

This should be equivalent tag instead of person right?

Should be tags here instead of persons

Is this javadoc accurate?

p.s. i think these 2 lines are common across the conditionals. maybe we can extract it out of the conditional? same for EditCommand

Is this part relevant?

Is this description accurate? I think the javadocs you have in AddressBook.java would be better here!

Based on the name of the method, I am inclined to think that this method returns a list of contacts. Maybe you want to rename it so it's clearer? Idk. But I think updating the javadocs would be good!

Same for findBySaleTag

Should this be be model.findBySaleTag?


     * Lists all sale items associated with {@code target} tag.

ps still got the parameter here that needs to be updated as well

Does using ++count instead work? Same for below

Maybe can replace this with just AddCommand instead of the fully qualified name?

Maybe can use AddCommand here instead?

Just checking, but what's the desired behaviour if a user supplies both c/ and s/?

P.S. I think I extracted this out into a method in ParserUtil. Maybe can import it from there instead of duplicating?


     * Returns true if all the tags of the provided {@code sale} item exist in StonksBook.


     * Returns true if all the tags of the provided {@code sale} item exist in StonksBook.

Thanks for pointing that out!

Oh, my bad. I didn't know the new line would affect the formatting. Thought it was just code styling. Will remove it!

Not yet! Just adding this in here so that I won't forget. Sorry for the confusion

@Asthenosphere ps can help resolve the merge conflicts?

LGTM

Thanks!

Think we're all done with this. Nice work all!

LGTM! Could you merge the updated master and push again though? Renaming CONTACT_INDEX to CONTACT_INDEX_SECOND might affect some of the test cases that have been merged.

Sure!

Not really relevant to this PR, but I think the parameter and example for editing a tag is missing the updated tag name. Example should be something like tag edit 1 t/furniture. Feel free to merge this PR if you want to resolve this in another PR.

Tested locally, LGTM! Good idea to abstract ModelStub out to another class.

Can I just check: whether a reminder is overdue or not is evaluated at program startup, are there any plans to either have the reminder display update immediately when the reminder time has passed, or to have a command to manually refresh the reminder display (like perhaps on reminder list?

Good point! I've added a force-refresh at the end of every command. Idk if this would be too inefficient though...

See #127

Done in #114

Yep, sure!

Perhaps javadocs could be added for the class here?

Perhaps javadoc comments could be added for this enumeration to further explain the role of this enum class?

We could use a common ParserUtil class to implement parsing methods which can be used across ModuleList, ContactList and TodoList in the future. For now, this is a sound implementation.

We could perhaps consider shifting out EditTaskDescriptor as a separate class rather than a nested class.

Perhaps this validation test could be modified to account for empty task name as well?

Perhaps you could extend a similar concept further and allow users to add tags to a particular task? The tagging feature seems to have some similarities with the Type enumeration here.

Will users be able to create Tasks without a type, priority or date? Perhaps allowing users to omit the addition of certain Task fields would increase flexibility?

Should we ensure that another task with the same name, date and type as the edited task does not exist in the todo list? This is in accordance with the hasTask method above which checks if there is a task with the same name, date and type.

Merge conflict here has not been resolved. Should be resolved as soon as possible.

Perhaps you can consider adding an error message for this exception so exception handling would be clearer for us and users will be aware of the incorrect or invalid command provided.

Would users have the flexibility to choose how the todo list will be sorted? Specifically, can they choose to sort from lowest to highest priority and vice versa?

Yes, I think it is sufficient to check the name for duplicate tasks. However, could you clarify the implementation of the above hasTask method? The javadocs says that it will check if there is an existing task with the same name, date, and type in the todo list. In that case shouldn't checking for same name be enough?

Yes, that sounds fine.

That sounds fine, this can be further worked on in future PRs.

The separation of the commandWord from the respective arguments in this line could be further refined using Pattern and Matcher class.

Perhaps for the implementation for ParserManager, we could abstract away the lower level details, ie the kinds of Parsers that exist (ModuleListParser, ContactListParser and TodoListParser). These Parsers would only be made known in ParserManager and LogicManager should not have to be aware of them.

For this method, we should avoid using the contains() method. Consider a scenario where the user inputs "module1" as the first input word by accident. Then "module1" would be accepted as a valid command word. This can give rise to bugs and complications. We could consider using .equals() instead.

Relating to the comment below, we could have ParserManager instantiate an instance for each of the 3 respective Parsers in the constructor here, rather than leave it to LogicManager since ParserManager is the one responsible for the 3 Parser classes. This is something we could consider.

We should first merge the PR which abstracts out the parsing of contact list, module list and todo list into individual classes. Following the merge of the above mentioned PR, please handle the parsing of Task related commands in the TodolistParser class.

Perhaps we can shift this Date class into a commons package in the model package. The rationale is that other implementations such as our schedule feature would require a Date class as well. This can prevent repetition of code.

Perhaps we can consider abstracting out all Name related classes, such as ModuleName, ContactName and TaskName into a common Name class. This would prevent repetition of code.

There might be a naming error in the javadocs here. It should be AddTaskCommand if I am not wrong.

Perhaps we could implement the tag feature of Tasks as a Set&gtTag> so that users will be able to add more than 1 tag. Based on this current implementation, users will only be allowed to add one tag. However, it is fine for now and we can make the necessary changes later during the milestone.

Is there a reason why you modified this String? I thought it is fine to include the message constraint that a task name should not be empty.

Yes, that makes sense, we could consider that.

Yes, that sounds reasonable, ultimately ParserManager should be the one handling the instantiation of the related Parser classes.

Contact should be replaced with Task.

JsonAdaptedContact should be replaced with JsonAdaptedTask.

All instances of "contact" in javadocs and variable names should be replaced with "task".

Will this class be required for the todolist storage implementation?

Perhaps you could use requireAllNonNull(todoList, filePath) from the commons package?

Perhaps you could modify this line to: logger.fine("Attempting to read todo data from file: " + filePath);

Since we are reading data from several Json files, this can improve clarity when using logger.

The comment from above could be useful here as well, we could refine the logger message to be something more specific and meaningful.

I think the implementation of this constructor can be improved. For a Task object, the Date, Priority and Tag fields are optional and the below implementation might result in a NullPointerException, for eg, invoking getPriority().get() might return null.

This is a temporary implementation as the storage for contact list has not been implemented yet.

CommandResult sounds more understandable as opposed to ResultCommand. The class is supposed to represent the command's result.

Same issue as above.

Yes, we do not want to add multiple contacts which are the same into the contact list. Thus, it is necessary to perform such a check for duplicate contacts.

Even if an object of List type is declared final, we can still add items into the list. We are only unable to overwrite the list with an entirely new list.

Same issue as above.

This will be updated during the next PR.

This will be updated in a future PR.

Yes will change it.

Yes this will be done!

Yes, email and telegram will be set as optional fields in future PR.

Yes, javadocs will be added.

Individual components of the user guide have been added by member's pull requests linked to separate issues. User guide has been updated with the necessary content for milestone 1.1, this issue will be closed.

Merge conflicts resolved. Able to merge pull request.

Should resolve CI checks before merging PR.

Issue is closed with the merging of PR #84

UML diagram has been uploaded to the repo.

This PR should still be a draft, it will be closed and a new PR with the updated storage functionalities will be made in the future.

ParserException and CommandException have been added in subsequent PRs.

LGTM.

Do we need to have 2 add here? coz it looks a bit weird from the preview

Will it be better if we separate the command word add with the example into 2 lines?

Or can just delete the 2nd add to just have a command word + command body format

would help page of Nuudle be better? or just another way to avoid not using 's

would the method name be better if it sounds like a question?

like isAppointmentOverlapping

it might be better if this public method could have a javadoc

That is possible.

Although the initial purpose of the DateTimeLoader class is just improve the OOP for the AssignCommandParser to pass the date and time, we can make it into an inheritance or other implementation to broaden the usage when necessary

If you want to get rid of the AssignCommand., I guess it would better to import the DateTimeLoader class so the code looks more precise.

Will the white space be too much?

do we still follow the user guide? coz from there the done should be with the use of the AppointmentId, so maybe it would be better to use AppointmentId class instead of dateTimeLoader?

I think this should be NuudleParser?

The package name should be nuudle?

Since here is for the entire project

I think the VersionedPatientBook also? Since the undo/redo includes the appointment

PatientBook should be Nuudle?

I have another idea tho.

Do we actually need to check the overlapping of target and editedAppointment? I feel not checking makes more sense to the reality where the patient just want to shift the appointment a bit forward or backward.

Let me know what you think about this 👍

Should the name be WithIn be one word? like Within

[REMARK] should be without square bracket?

I'm not sure about this, but usually there is no space between prefix (r/) and content (Likes to swim) right?

I think we need a short description before the @param?

I think this should catch ParseException since the parseIndex throws it and no mention about IllegalValueException

I went to check and found out that actually we have not tested this try and catch block for other commands.

I guess we can add in V1.4.

Good effect for all remarks! 🤣

Oh that makes sense 👍

I would think that we should disable cancel if the date of the respective appointment to be cancelled is alright passed since there is no point to cancel an appointment which is already in the past.

However, I think it would be different for done since there may be cases that the admin forgets to mark done and just lets it expire. done allows for the correction.

How about the rest?

should be checks?

is period needed here?

Thanks for the correction 👍

The space between addressBook and the ... is too much?

Should be Creates?

I think can remove at?

Just like the one in DateParserUtil.java

have should be singular?

I would think this helps abstract information.

The only problem is that we need to arrange it well.

Maybe we can clean it up in some time.

Would a short description of the method be better?

🤣

How about we take out our code of the EditAppointmentDescriptor and DurationSupporter to have a common class!

I have to say it too!

It solves the warning from get() of Optional!

Thanks for the enlightenment.

Should we check in the other way?

Coz in this case, the command can be successful with even just one of the prefix content present. Hence isPresent() should be used instead of isEmpty()

I think you can refer to the EditCommandParser class

What do you think? 👍

Sorry that I'm a bit confused why all the numbering is 1?

Is it supposed to be that?

alright!

Yes, thanks for pointing out

Yup, I did use PREDICATE_SHOW_ALL_APPOINTMENT, but just due to bugs of ystd, I doubted it was related to it so I changed. After solving the bug, forgot to add back.

Thanks for the suggestion!

Hence, it actually indicates an invalid command format if PREFIX_DATE is empty as it would mean that something else is written

@Avalionnet yup, I covered empty arg in the switch cases in NuudleParser, which is just list other one word command

but now I have changed to cover it in the ViewCommandParser

I think both ways are good, what yall think?

Thanks guys!

Yes that is good indeed, I have changed it.

Good spot and thank for pointing them out!

Definitely!

And I just realized that use in minutes to express it 🤣

I think that is simpler and clearer?

Haha, you too!

Good job reviewing all my codes 👍

Oh, this UI part has been done by Yang Yue, so I guess this one can just ignore.

Good spot!

Oh this part is supposed to be Ming Lim's, I accidentally touched it.

Hmm if I remember correctly, we are required to use lowercase for naming our profile image file. Do check it up before merging!

Noticed. Changes have been made 👍

Should this document need to be refactored?

Should we edit the tutorial document?

Perhaps this document does not have to be edited as well?

Is this part of a tutorial as well? Should it be changed?

Perhaps we should keep this in view?

Should we change "ab" to "mb"?

Same as for UndoRedoState0.puml, maybe we should change in all the diagram files?

Should this be changed since there is a link to AB4?

Good renaming here!

Does this document need to be changed? I'm not very sure 😕

Should the tutorial be refactored?

Should this be changed?

Should this be "MediBook" instead? Since it looks like the product name

Is this refactoring the correct word?

Similar to a previous comment, is this the correct thing to change?

Again, should this be changed?

Should this be left alone?

Should this be changed?

Here as well

Should this comment be changed?

Should the comments in this class be changed?

Should this be refactored?

Should this be changed?

Should these comments be changed?

Should this be changed?

Should this comment be revised?

Perhaps change this to "MediBook" as well? Not that important as it's just for logging

Was this supposed to be changed?

Here as well

Perhaps change this variable name?

Perhaps the comments in this class can use "MediBook" instead?

Should "ab" be changed?

Sounds grammatically incorrect to say "the user then access" even though it is clear in the markup that this is a command. Is there a way to rephrase this sentence?

Good eye 👍

Maybe we can refactor this if needed after looking at the implementation? Since this is based on conventions in the other Patient detail classes i.e. Name, Tag, etc.

Will that make the code harder to read and be a bit unnecessary? I also made it similar to other classes so maybe we would want to be consistent?

Will create a PR on branch instead of master

Resolved by #80

Resolved by #80 using UI parts instead

should this be mid-v1.2?

okay agree

I got the same warning and also mentioned here: https://github.com/nus-cs2103-AY2021S1/forum/issues/232

(it's an error log output). So this should be fine

Should the parameter name be client instead of Client?

Should the parameter name be clients?

should Clients be clients?

ohh, if the checkstyle version/file in both GitHub and IntelliJ are already configured properly but the outputs are different, I'm not sure which one to follow. Perhaps @benclmnt have a suggestion regarding this code quality?

I think this is what wei jie means. Perhaps you can change these jsons from "Clients" to "clients"

Or should we ignore the GitHub's checkstyle warning for now and merge, and fix it along the way?

Should this be FitEgo?

Should this be Clients or clients? (for consistency)

should the name be something like "hasFunctionToRun"?

Should this be non-public?

should this be session builder? noticed the same cases in this file as well

should the variable name index be changed? since there are 2 "index"

just curious, any reason why this takes in LocalDateTime instead of String (since the other with__ takes in string)?

in terms of consistency with the other with__ methods, should we pass the String? What do you all think?

should FitEgo shows list of client and session?

should this be inside [] to show this is optional?

are these 2 fields used? In editClientDescriptor, the index of the entity that we want to edit is not included. Only the fields that might be changed due to the edit command are included

will this throw NoSuchElementException if the input does not include su/...? This issue arises when implementing payment/adding schedule remark features. I think would be better not to declare it here, since if the schedule remains unedited, it's already handled in line 71

Should these 2 lines be wrapped in a try-catch block, like the EditSessionCommandParser and EditClientCommandParser to check whether the clientIndex or sessionIndex is missing?

should the edited field, i.e. updateSessionIndex be encapsulated in editScheduleDescriptor?

should this takes in updateSessionIndex only? since the field that would be edited is only session index (for now)

should updatedSessionIndex be encapsulated in editSchedDescriptor?

for consistency, do we need to add what is contained in the client?

command change to commands?

should we write "commands" instead of command?

should we include "weight measured"?

this might change if we want to use ses and sch

should we say duration is in minutes?

should this be session list?

Would this mean we need to have this extension in every command? (extension if we have a missing argument)

now pd/paid or pd/unpaid

Is it better if I change it into:

Use case: UC03 - Edit a Client

MSS:

    1. User requests a list of Clients using `clist` (UC02) or `cfind` (UC04) 

    ..the rest

done

sessionIndex is the previous index (index of session to change)

the reason I delete the updatedSessionIndex is because it is already contained in the descriptor (since this is an optional field). also, I'm afraid that if we have updatedSessionIndex in both command and descriptor, we must ensure both of them are the same

@benclmnt any comment?

thanks for spotting them, that was auto-filled by IntelliJ (because ModelStub implements Model).

I'll change it

yep, it represents phone in add client cmd. Do you have any suggestion for this?

im thinking of paid/ or pay/, but afraid that those are too long

i think maguire is editing this part

yes, it works even without the true. not sure why @benclmnt also have the true in the cmd usage message

oh @kelvinvin 's suggestion is to have the else to make it clearer

so make it like the prev commit?

should the find feature be implemented later? Also, the current AB3 only supports search by name

Is this like adding a new command? If yes, should this be for v1.2 or mid-v1.2?

The division of 3 sections is in the other PR. Should we bold the nextSession line?

sorry just read this. both bolded/not bolded looks good for now

Some things to take note:

1. Command has been changed from "[c/CLIENT] [s/SESSION]" to "[INDEX] [s/SESSION]" which makes more sense.

2. 1 issue which is that when the input session is higher than the total number of session, there's an exception on the terminal but nothing is being printed on FitEgo. The issue is with RescheduleCommand only having the [INDEX] which takes care of the problem when [INDEX] > total schedules, but in Parser, I'm not able to retrieve the filteredSessionList as it requires Model to retrieve it, so FitEgo can't detect the issue when input session is higher than total sessions.

3. Testing for this Reschedule is not fully up yet because there isn't a ScheduleCommandTestUtil class, not sure if this is required because now it's a bit tricky in a sense that Schedule contains Client and Session while RescheduleDescriptor contains clientIndex and sessionIndex of Index class. If RescheduleDescriptor were to contain Client and Session, it should be easier but in RescheduleCommandParser, similar to issue 2 above, I'm not able to retrieve the filteredSessionList as it requires Model to retrieve it.

try to detect the issue in command.execute() instead of parser?

A good feature to have. will the implementation be like inside DeleteSessionCommand, iterate through the model's ScheduleList?

looks good

solved

Should PR from branch

i've implemented some of my suggestions from here to my payment PR

feel free to try that feature and see if there is any unecessary changes made

Can anyone check if this is correct? The new diagram is a bit different

Before:

Now:

Looks good generally

resolved

added just now

Small issue, but should this line not begin with a whitespace? (Even though the syntax highlighting does not appear here on GitHub, I believe it still works to markdown the text in this case so shouldn't be an issue!)

Should we markdown these lines with backticks as well, to put them in code format, as per the other examples?

I assume we're using Person's Name and Phone classes for now since they help guarantee certain text properties. We'll probably have to change this in the future (at least the naming, for example wage being a Phone object seems odd)? Perhaps using String for now may keep things even simpler, but I suppose this works for now!

Perhaps we could name this InternshipStatus or something along those lines instead? Do let me know if I'm mistaken, but it seems that we have a Job class that has the variables - jobTitle, companyName and industry. So this status object should be reflective of an Internship status rather than a Job status? Shall we ensure that "Job" and "Internship" are not interchangeable terms throughout our code base? Another issue that might still arise even after changing the name to InternshipStatus is that we will then have a Status and InternshipStatus class, and it may not be obvious what the difference is between the 2 in terms of their names? Would it be possible/better to make this a private enum within the Status class?

I suppose having this field means in the UI, we'll have some text like "As of: date"?

As we'll also need to add Jobs in a company object, this Job object seems to differ implementation-wise from the Job object that we may use for company objects, though they should probably be the same? For example, in a Company object, during its creation via a user command, the user can input multiple industries and jobs that a company has. This creates the Company object, along with its multiple jobs and industries. So in those Job objects in the Company object, will each of them have multiple industries tagged to them instead of just one industry as in this Job object? Also, since a Company stores Job objects, would this create a cyclical dependency if we change the Name companyName part to Company company in the future (I assume we will)? At this juncture, it seems that if Job is going to store Company and Industry, perhaps we may not even need Job objects? Perhaps we could simply use String (or Name) for jobs? This may also help to synchronize with how jobs will have to be represented in a Company object.

Sounds good to me! Shall check with the rest if they're okay too! (Sounds like in the future we could perhaps repurpose the "Person" package to become like a text-format-enforcer package of sorts?)

Ah I see, thanks for the clarification! I think the Status and ApplicationStatus names suggested work, but perhaps sticking to InternshipStatus might still be better so we don't introduce more terms for the same object (for e.g. application and internship both refer to internship applications)? So maybe swapping the current Status and InternshipStatus names will do? May have to consult the rest haha, just some suggestions!

Ah okay! My bad for missing this out, thanks for highlighting!

Should this return companyName instead?

To stick to a standardization, shall we also rename the InternshipApplication class to InternshipApplicationItem?

I believe these attributes for Company and Internship are the outdated ones?

I see we've changed the tab name from plural to singular. I was wondering if it would be odd since the user would be looking at a tab labelled "Company" but in it can be multiple companies? Likewise for "Application" as well, which to me sounds like I'll view a single application if I click on it. Small matter but perhaps we could discuss this further and see what the team thinks too!

Alright, no worries! Will merge this first and we can settle this next time.

Just to confirm, does company application refer to internship application i.e. our application class in this case?

Ah I see! Thanks for the clarification Sean!

Just tried using the same line of code for the add company command I'm working on and yep, even upon successful addition of a company, this line of code does not switch tabs. Will follow Isaac's observation and see if I can make it work for add company in the time being!

Just tried successfully on my end for add company command, regarding the switching of tabs, changing this to return new CommandResult(String.format(MESSAGE_SUCCESS, applicationItem), false, false, true); will do the trick!

This works if all our commands require a switch? At the moment that seems to be the case apart from the help and exit commands if I'm not mistaken. Also, I suppose it depends on how we want our app to behave exactly - do we want it to switch every time a command is executed even if the user is already on the right page, or do we want to switch only if the user is on the wrong page? I suppose this may not be detectable visually unless the switching of tabs introduces its own behavior (for example if switching causes the list of cards to jump to the top of the list, and not switching allows the user to stay at wherever they've scrolled to in the list, then executing a command that always switches vs. one that only switches when necessary will provide different user experiences).

Should the second argument be AddProfileCommand.MESSAGE_USAGE instead?

Should this be outside of the exceptions package?

Minor nit, but perhaps we could change this to setRequirements in the future? Just to keep all the namings consistent.

Same thing regarding the tags naming here. Unless I'm misunderstanding the use of the word "tag" in the context of this UI portion of code. Apologies if that's the case!

Perhaps this newline is an extra addition?

Now that the return statements have been shifted into the if-else block, I think there may not be a need to declare a String resultMessage variable anymore on line 40? Perhaps we could just use return new CommandResult(sameScreenText, false, false, false, false); on line 44 and return new CommandResult(switchedScreenText, false, false, true, false); on line 49. This would help us keep in line with the coding standard rule - "Variables should be initialized where they are declared".

Does reintroducing this line reintroduce the issue we faced where the user is currently on a tab and wants to view something on another tab, the app will switch to that tab but always show item number 1? (for e.g. user is viewing company tab and executes view me 3 and the app switches to profile tab but views the first item instead of the third)

As all our list commands are going to have similar success messages, perhaps we could do what we did with the rest of the commands which would be to add something like this after line 25: String listSuccessMessage = String.format(MESSAGE_LISTED_ITEMS, APPLICATION_NAME); where MESSAGE_LISTED_ITEMS resides in Messages.java and goes something like: "Listed all %1$s items";? Just a suggestion!

Is this redundant given that ListApplicationCommand can use ListCommand's COMMAND_WORD? This is with regards to how all the other commands exhibit the same pattern in that they use the parent's COMMAND_WORD.

Super minor point, but with regards to the phrasing, I suppose this might read a little awkwardly for more than 1 item found, such as "3 company listed!"? But it's just the phrasing so it's not a big deal and we can probably handle this in the future if we want!

Will this throw an inappropriate error message? Correct me if I'm mistaken, but does this throw the error message "Item type has to be either 'com', 'int', 'app' or 'me'"? If so, I believe that since we can't run switch int, should we revert back to the old error message / something along the lines of "Item type has to be either 'com', 'app' or 'me'"?

Should we be using model.updateFilteredApplicationList() instead to avoid LoD violations?

oh yea great idea!

Yup true! Sounds good!

True, this class is indeed very similar to the Name class. However, in order to do the following:

pass in the messageConstraints to signify a different error message if need to

perhaps we can modify the Name class to, say, take in an extra argument in its constructor for the messageConstraints variable, and then the passing in of this variable could be done by the Industry class that extends the Name class and simply passes its own messageConstraints through the parent (i.e. Name's) constructor via super(). As such, we'll reduce code duplication but still maintain the existence of the Industry class. I feel that it may be necessary to have such unique classes because variables such as private final Set&gtIndustry> industries = new HashSet&gt>(); would look rather odd as private final Set&gtName> industries = new HashSet&gt>();. And ultimately, in order to "pass in the messageConstraints to signify a different error message if need to", I believe we'll still need to have some sort of Name as parent class for subclasses such as Industry, Descriptor, Requirement, etc. arrangement, since Industry is not the only class affected by this / has this characteristic.

All that said, modifying Name and abstracting all the common fields to subclass from it at this juncture would be inappropriate in the context of this PR. Would it be okay if we let this portion through first and do the necessary abstraction / refactoring after all 4 items (inclusive of this Company item) are present in our codebase, as discussed in our Tele group?

My bad, thanks for catching this!

Oh yep great idea! I've made the changes!

I can't shift it straight into the current if-else block due to the nature of the condition checking. If we want to make it all part of one block, here's an option:


if (model.getTabName() != TabName.APPLICATION) {

    model.setTabName(TabName.APPLICATION);

    shouldSwitchTab = true;

    model.setViewIndex(targetIndex);

} else if (model.getViewIndex().equals(targetIndex)) {

    resultMessage = messageAlreadyViewing;

    shouldSwitchDisplay = false;

} else {

    model.setViewIndex(targetIndex);

}

But this means model.setViewIndex(targetIndex) appears twice.

Another option is to simply remove the if condition and do:


if (model.getTabName() != TabName.APPLICATION) {

    model.setTabName(TabName.APPLICATION);

    shouldSwitchTab = true;

    model.setViewIndex(targetIndex);

} else if (model.getViewIndex().equals(targetIndex)) {

    resultMessage = messageAlreadyViewing;

    shouldSwitchDisplay = false;

}



model.setViewIndex(targetIndex);

But this means that even when the model's view index is already the index that the user inputs, we still set it anyway (unnecessary call to setViewIndex). It won't affect the program though.

Between the current code and these 2 options, which do yall think is better? Or are there other alternatives yall may have?

Hi Keane! Unfortunately that would not be possible. Variables can't be declared in an if-else block and then used outside of it due to variable scope. Even doing something as simple as:


if (true) {

    boolean shouldSwitchTab = false;

} else {

    boolean shouldSwitchTab = false;

}

shouldSwitchTab = true; // line X

Will lead to an error on line X whereby it doesn't detect that shouldSwitchTab has been initialized.

(More on it here: https://stackoverflow.com/questions/17444020/why-cant-variables-be-declared-in-an-if-statement)

As such, this already is the smallest possible scope!

To justify having these boolean vars initialized and declared where they are, we can take it that by default, we assume the user in on the appropriate tab (shouldSwitchTab = false) and not viewing the current item (shouldSwitchDisplay = true) which is why they would want to execute the view command in the first place. However, they may happen to be on the wrong tab (first if statement checks for that), or they may happen to be on the right tab and already viewing the item (the following else-if statement checks for that). That is how I would intend the code to be read!

Ah good question! I raised this in our Tele group last night, but basically how the view index works is that it takes the index from the tab that is currently in view. So for example, if a user is on say the Application tab and he is viewing the 3rd Application, if he executes view com 3, if we do not check for the tab first, then the program will simply think we're already viewing the 3rd item so it doesn't need to do anything, which is wrong of course. That said, now that you've raised this point, I believe I may be able to abstract away the first if statement, but I'll definitely need that condition check in the else-if statement that checks for if the user is on the same tab and currently viewing the indexed item. So I can minimize the tab checking but we need that one minimally.

Ah my bad! But then will we be violating this coding standard rule?

No problem, thanks for highlighting! Have made the changes!

Oh if that's the case, sure I don't mind changing it! But then again I'm not sure if our evaluators have the same understanding though? For example when we eventually evaluate our peers' work, I would probably follow the coding standard to cross-check my evaluation and if I spotted this violation in their work, I would probably just mark it as a violation since it is stated in black and white and not have to think too much. If you have the source, could you point me to where Prof Damith mentioned that we could do otherwise? Would be much appreciated!

Overall looks great. Good job. Just a few nits and it will be good to merge.

Thanks for pointing them out Sean! Have gone ahead to fix those inconsistencies across the whole doc.

Overall looks great! Just wondering if grouping the 2 stars and 3 stars together would be better? Perhaps edit an object should be considered a high priority as well? Otherwise LGTM

Ok! Made the edit commands high priority, which solved the 2/3 star grouping issue as well!

Hmm. The dilemma now is that this is just a proof of concept and we may be abstracting common logic down the line and scrapping all these, so overwriting Javadocs now may redundant. The danger is that if the code is kept and the comments are missed in the future. What is the team's opinion on this? @ZoroarkDarkrai @keanecjy @seanjyjy @shawn-nyk

I agree that overwriting Javadocs now may be redundant, especially because our code can change over time up until the final version. At the same time, I also agree that we may miss them in the future, and doing a one-time run-through of all our code at the end may be very tedious and error-prone. As such, how about we do something like: every time we create new bits of code that require Javadocs, or we modify code that already has Javadocs attached to them, we place a standardized comment, such as TODO: Javadocs above the code we need to write/edit Javadocs for? That way we get the syntax highlighting that IntelliJ provides for the TODO keyword, and we can also search for this standardised comment throughout the code base to hone in on where we'll eventually need to write/edit Javadocs when the time comes. Any thoughts on this?

Great work! I noticed you helped to check all our commands to ensure consistency in the messages too. Just need to fix some checkstyle issue before merging can be done.

Thanks Keane! And oops my bad, made some last minute changes and pushed after I first made the PR (introduced some checkstyle errors in the process). I've made a few other further changes to remove some hard-coded messages and make our add commands' success messages similar in execution to that of delete commands (calling upon the Messages class). For your vetting!

Besides the point that @keanecjy has raised, I believe it is good to merge after it is resolved.

Thanks Sean! Have made the changes!

To explain this code:

Line 43 executes a function that creates delete int commands and executes them, causing the model's internal tab name to be set to company. Thus, before that line is executed, we need to save the current actual tab the user is on, which is done in line 40. Since we are checking against this saved tab instead of the model's current tab (would become company because of line 43), we cannot use the CommandUtil.getCommandResult() method.

@seanjyjy is going to redo this part(?) so should I ignore this?

Could be confusing saying job name because the format actually uses the position of internship in the company?

I don't think these are the right precondition and guarantees?

just a nitpick but I noticed that other use cases use list user profile items instead user profile item?

shouldn't precondition be the state of the system and not the user?

Another nitpick, maybe it's better to use InternHunter rather than the app? As the next points use InternHunter rather than the app?

I think you missed this comment?

I think you missed this comment an others below too?

should be instanceof UserProfile?

is it the user profile?

type is category right? because it can only be either education, skill, or achievement should it be an enum instead?

I assume this is a planned extension for the profile items to have tags?

should be two profile items? and several comments below

should be profileItem? and for other comments below too

wrong exceptions in this file or are they placeholders?

Is it switching to the applications tab?

I noticed you changed of a company to in a company for others

for consistency maybe use tab because we usually describe them as tabs and not pages(?) for this and others below

this is a really small nitpick but i feel the flow of the second sentence can be improved? just feel a bit weird having the if any in the middle.

maybe something like any applications with the deleted internship, will also be deleted?

is this safe when string length is &gt= 1? or is it guaranteed that the length > 1?

validity?

any reason why an assert instead of an exception?

CMIIW:

2 application items are equal if their internshipItem, status, and statusDate are all the same.
deepDelete uses the above equality to delete things.
ApplicationItem(internshipItem) will create a new application item with the default status and statusDate
The application with the internship we are deleting may not have the default status and statusDate?

shouldn't this be the javadoc for the method below?

isn't util just a general purpose utility class?

Why does it have higher cohesion?

Isn't low dependency --> low coupling?

"Coupling is a measure of the degree of dependence between components, classes, methods, etc. Low coupling indicates that a component is less dependent on other components." ?

"Only dependent on the one Item type" --> low dependency --> low coupling?

what is this for?

i mean if it's abstract it can't be initialized anyway right?

internship?

I think i missed why is it limited to 2 words in particular?

honestly I don't think this is a good idea?

suppose the requirement is "c" a common programming language, it will literally match with any word with a letter c (like cooking) or java with javascript, etc.

oh yeah, thanks for noticing 😅

Sure!

Yes, would it be better to start from empty ones? Will change it then.

Nope, the storage just need the isValidMethod

Ahh forgot to change it back, was testing. Same with the application item one. Thanks

Hmm, it's copy and pasted from AB3's. Hahaha.

Sure?

I noticed that many of the javadocs used "person" and "address book", should we change it now? or leave it for later?

LGTM, good work! Some merge conflicts to resolve first.

Fixed!

lol i just pushed the change

I think it's okay just I find many hard coded strings can be converted to const. If urgent can merge now and fix later?

Is it not normal to use hard-coded strings for test cases? Could you point on where exactly is the issue? Thanks

I mean the toString, equality, hashcode tests. Could use VALID_WAGE, VALID_PERIOD, etc? If it's a better practice to use "Sunday", "React Native", etc. it's fine then.

I think it's okay just I find many hard coded strings can be converted to const. If urgent can merge now and fix later?

Is it not normal to use hard-coded strings for test cases? Could you point on where exactly is the issue? Thanks

I mean the toString, equality, hashcode tests. Could use VALID_WAGE, VALID_PERIOD, etc? If it's a better practice to use "Sunday", "React Native", etc. it's fine then.

Not too sure what's the correct which is the correct way, but I just thought that doing it this way by writing 2 strings that are different objects would be better since we will be comparing periods with different strings in the actual implementation too

Sure then! I just thought maybe using constants could make it easier to see, that creating an object with the same input will result to an equal one. Like 2 objects created with VALID_PERSON_ALICE are equals but not with one created with VALID_PERSON_BOB.

LGTM!

I don't think you should be writing tests for ApplicationItem, Status, and StatusDate? Since we should be writing tests for our own classes and not helping others write their tests

Oh, I think I misunderstood then. When I said I couldn't do the storage ones then because lack of sample data, I think someone said I should do the application ones. So, do you want me to remove them?

I don't think you should be writing tests for ApplicationItem, Status, and StatusDate? Since we should be writing tests for our own classes and not helping others write their tests

Oh, I think I misunderstood then. When I said I couldn't do the storage ones then because lack of sample data, I think someone said I should do the application ones. So, do you want me to remove them?

Oh what I meant was create sample data for the storage tests and not to test the application classes themselves. So the rest of the files can stay except for ApplicationItemTest, StatusTest and StatusDateTest. Hope this clarifies!

Ok, removed them!

LGTM!

Nvm I'll just merge this first

LGTM, need to resolve some conflicts

resolved

Would item added to inventory be better?

Should we add the app's ability to handle table reservations and pending deliveries? (like in Mock UI)

Since this is the final product's aim

If I rmb correctly, the following word after @return it should be the type, then description for subsequent words

Is this change to /11.0.1 automated by your intellij system or you changed it manually?


                &gt;StackPane fx:id="deliveryListPanelPlaceholder" minHeight="-Infinity" prefHeight="440.0"


    private StackPane deliveryItemListPlaceholder;

Just to keep it more consistent with itemListPanelPlaceholder, what do you think? Just some minor stuff

Is this meant to be DeliveryListCard.fxml or sth along that line? Or you plan to merge the different cards into same style hence they both refer to ItemListCard?

Is this misleading? chicken and CHICKEN is meant to be the same?


* Only full words will be matched e.g. `chicken` will not match `chicken`

Shall we have multiple summary tables for each component (inventory vs delivery), since not all commands necessarily overlap?

Nothing to change here, just need your suggestion. I can make the amendments in my PR.

Thanks for abstracting this out for base Model.

We'll follow this moving onwards 👍

Oops sorry didnt read properly, thought it was a typo!

And should be phone, not quantity! Hahah


            + PREFIX_ADDRESS + "ADDRESS "


            + PREFIX_PHONE + "PHONE "

Can just check why are the types opposite?

Ah nvm my mistake, understood whats happening alrd

I'm not really sure with myself either, but doesnt RAM depends on the user's device?

Not sure if this is relevant? Feels abit iffy to me

It doesn't need a network at all? Refer to number 14

Do you want to include the key arrow up feature to go back to previous command entered in commandBox? Trivial but like cool only

Was actually thinking to let @wengfaing do this part since he needs some boost to meet his functional code req! (Maybe for the other help start window)

You mean Models#undo for the second one?


<div markdown="span" class="alert alert-info">:information_source: **Note:** If the current pointers are pointing to the latest state, then there are no undone InventoryBook/ DeliveryBook states to restore. The `redo` command uses `InventoryModel#canRedo()` and `DeliveryModel#canRedo()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.

Frm my understanding NFR needs to be something that is within our control, but in this case its more like dependent on the user and not within our control. Maybe can be rephrased like: Storing 100 states of undo and redo command models should take up less than ... Kb?? What do you think

Quite curious about this as well. Maybe we should summon @AaronCQL ? Hi what do you think

Nah its ok! whats done is done dont have to revert back because you alrd spent the time and effort


Step 5. The user then decides to execute the command `list-i`. Commands that do not modify the inventoryBook/ deliveryBook, such as `list` and `find`, will usually not call `Models#commit()`, `Models#undo()` or `Models#redo()`. Thus, the `inventoryBookStateList` and `deliveryBookStateList` remain unchanged.

I think 6 and 7 can be combined!

Wanna specify the commands? Maybe add delete these basic functionalities can be 1s. Then sort/ find can be 2s? Regardless of data size

I dont really understand this though, is there a better way of rephrasing?

Sounds iffy and seems like something that is googled and copy pasted hahah, shall we remove? I think quality > quantity

Would it be relevant? Because we know that this is a software and not hardware

@halcon-blanco thanks, amended!

Sure, I will include a different colour for that as well

Made the necessary changes including the test case

@halcon-blanco Thanks for pointing out, I've changed to saveDateTime

@zeranium97 Thanks! Updated

Thanks for spotting, remedied.

This is for the case where restocking is needed, etc

Should add be able to handle restocking? Ie whereby if the name and supplier is the same, quantity of that particular stock will be increased by the amount stated.

LGTM, rmb to accept and merge with previous PRs first (if possible) to prevent excessive conflict next time 🤙

Thanks for the name refactoring, LGTM

Thanks for info, will trace and refactor this to make it work and PR again

LGTM 👍

You have to rebase/ merge with master first and deconflict before PR or it will get rejected

Oops sorry I just realized this is for tutorial.. I thought its meant for actual PR to be merged hahah

https://www.figma.com/file/bwoqFizIJKUu1bA8WqLzuq/Untitled?node-id=0%3A1

@xnoobftw one way is to not put preferences.json inside gitignore, but this default value is meant for first time users. Since all of us are developers, its okay to delete it (because users perspective as first time users they will not have the preferences.json)

LGTM for this version, we will make further nits along the way in this project for UG DG 👍

@wengfaing do you want to add the relevant unit/ integration tests first for this command? Including parser for the command, logic, etc. Or do you prefer to do these tests in next iteration?

Sure, LGTM for this implementation! We can make the remove unit tests' tasks during next iteration

@halcon-blanco @xnoobftw understand that you guys are working tgt and need to pull from each other, but a suggestion would be to merge a feature-in-progress in another organization branch instead of master next time, just for a good workflow practice but no big issue 😃

@zeranium97 there's conflicting files, just rebase your commits and we'll review again 👍

A delivery model requires name, phone, address and order. Is the PR meant to be complete or is it WIP? Just checking because I can't seem to find any of these in the PR

It's to be implemented by @zeranium97 when he implements storage

Ok sure, since its in another branch we'll merge it first. Praying hard it'll work well so that we can merge into master 👍

Errors not caught:

remove 1
remove 1 q/-123
remove 1 q/
remove 1 q/ASDF

Would be great if you can do unit testings for these too. Thank you! @wengfaing

@halcon-blanco i'm fine with this, since we might need to change again in the future into 3 sections so no issue. For the colouring, is it easy to implement colouring to be conditional (red vs green if stock falls below 20%)? If its a huge task we can create a separate task.

Further improvement:

Low priority: I didn't do the GUI for help toolbar on top to open up the 2 different help windows since the app is meant for CLI primarily. But feel free to connect them if you want 😃

WIP: as discussed in #95

GUI help window toolbar
Colouring difference (red vs green)

Please tick once done so that we know when to merge 👍

@zeranium97 oh yes remember to assign PRs you made to yourself as well as the milestone. This one is just for admin purposes so that cs2103 can track (yes it doesn't matter in v1.2b but just reminding for future milestones)

@zeranium97 Are you also catching other exceptions as the scenarios mentioned in #105 comments?

@Wincenttjoi I've made the changes you requested, plus changed the whole structure of the DeliveryList GUI to match that of the ItemList. (Tonnes of headache cuz debugging GUI is super hard).

I also wrote the basic code in MainWindow.java for initialising the values into the DeliveryList on starting the app, with currently an empty ObservableList being initialised temporarily. The Delivery class I wrote is also currently just a stub with no functionality.

Thanks for changing and doing more than required! LGTM

Do you plan to do the other exceptions? If not then I can merge this PR first for now. Thanks @zeranium97 !

@xnoobftw @halcon-blanco sure, if want to make it flexible its fine too. I'll close this thanks!

Is there any other exceptions I might have missed out for this command?

Only those 4 checkboxes i've put in #105. Can't really check if it works for all 4 in my internal application since we're still forced to do in forking workflow. If all's good then can merge 👍 Help me check on your side please

LGTM thanks!

its ok @wengfaing i'll help you do the tests

Just want to check if you're bothered by the naming? Because sometimes I get confused that Item is actually referring to only Inventory. Sometimes I would think of Inventory item vs Delivery item (Item is the umbrella term for the different types)

Any thoughts for this? If you're okay with I'll see what I can refactor in next PR too

Just want to check if you're bothered by the naming? Because sometimes I get confused that Item is actually referring to only Inventory. Sometimes I would think of Inventory item vs Delivery item (Item is the umbrella term for the different types)

Any thoughts for this? If you're okay with I'll see what I can refactor in next PR too

I think our understanding is that Item refers solely to inventory item

Ok can! We'll keep it as such then np. LGTM. Test cases we will push it to nxt milestone!

@AY2021S1-CS2103T-T12-1/developers do you guys prefer to standardize Order to not be able to accept empty string or just space? I can add the VALIDATION REGEX if you want, because the rest of the delivery objects seem to have this as a minimum req.

things to be added

Command & Parser testcase

Are you planning to add it in this PR or another PR?

I will be adding it into this later tonight

@zeranium97 Ok, normally a common practice that people use if the PR is not ready they will use WIP in the header. Changed for you! **Ofc the CI needs to be put first and I just made a PR for that

We PR once u done the test cases first?

LGTM thanks!

@zeranium97 U forgot to add a test for the add parser

In case you wanna do feel free hahah!

@xnoobftw If you are okay with implementing, I think it would be good to return a message on the commandbox to make it consistent with other commands

@xnoobftw If you are okay with implementing, I think it would be good to return a message on the commandbox to make it consistent with other commands

May i know what you mean by this?

So an example would be after the command sort ... a line should return on the command box

A possible reply would be like: You inventory item/delivery is sorted according to .............

@AY2021S1-CS2103T-T12-1/developers sorry that I couldn't attend the impromptu meeting. Just a short question, I'm curious why exactly sequence diagram for delete command but not others? Is there a specific reason?

@xnoobftw

do you want to add small note on ur diagram to briefly describe what XYZ is?
Arrow for &gt&gtInterface>> Parser on the Parser section is abit misleading, mind to remedy that to make it more coherent?
Perhaps you can also bring the Command and Parser box bigger (filling up >80% of the space) bcs there's too much white space and its too small for people to see. Size of individual blue boxes can also increase in size if you dm 👍
Executes labelling on command part not clear on which line it should belong to
HelpCommandResult extends from CommandResult missing
I think there's no more concrete XYZCommand since they are all extracted to the smaller commands (items, delivery, help)

Sequence diagram for logic seems ok

@AY2021S1-CS2103T-T12-1/developers feel free to discuss bcs i'm not 100% sure either

Will do!

Do you mean having a solid line? Because it's how its represented in AB3

Do you mean increasing the font size?

The PUML auto generates this D:

Added! Thanks

Redo, Undo command still does! exit too

@xnoobftw

Nope, I only meant the starting point of the line bcs its overlapping with the line on the left
The overall box size as well as individual boxes (inside) size, and font size

Oops its fine then!
Yes just realized that too, my mistake!

@xnoobftw try to occupy the diagram >80% of the picture! If not too small hahha.

Edit: I realized that we can't reposition the arrows, just saw the documentation hahah. Not sure if 2 is doable

@halcon-blanco I think this must be done before tutorial!

Idt 2 and 3 is doable due to puml automating it

But does this fulfil ur requirement!

@xnoobftw

Can check this out for 3 https://plantuml.com/skinparam

Reason being is because we need to make our dg comprehensible thats why we shdn't just leave this out even though it seems trivial

Yup looks good! (Apart from box sizing)

Increased fontsizes to 30!

Thanks! Sorry one last thing, you forgot to change the link in your Logic component description, its still referring to addressbook link

@xnoobftw oh thanks. Its bcs I saw not green yet in the team project progress hahah, thanks!

LGTM thanks!

@AY2021S1-CS2103T-T12-1/developers the rest going to review? I might missed out on a few things here and there.. Would be good if everyone take a look before approving DG PRs

There's a couple of errors in the diagram! Check out the ss i tagged

Does inventoryModelManager has Item? Not sure about this, or is it referring to the FilteredList&gtItem> filtered Items?

Same goes for deliveryModelManager

And another update! I dont see a uniquetaglist class in the folder unless im mistaken! and i dont think we should show inventory book in the item class diagram

Actually I think its fine with or without the InventoryBook, because the reader can see how its connected to the component outside Item. Seems like @zeranium97 has changed it to without but im fine with either! (Personally think with is better tho)

@halcon-blanco you can CTRL F address and see the relevant addresses to be changed hahah, still got more

LGTM Thanks!

@halcon-blanco made the changes as requested

maybe leaving commented code could get confusing in the future?

@Wincenttjoi

hi @Wincenttjoi

Perhaps initializing maxQuantity to a value other than "0" is a better idea? Similarly to tags maybe leaving it empty is fine

Perhaps not checking is fine too? Since we do not require max quantity to be a mandatory field. Having this check will go against our design

Similarly if maxQuantity can now be empty i think having a method to check if maxQuantity is null prior to this block of code would prevent a parsing error

Similarly to tag i think initiazing to a 0 is not a good idea because we'll eventually be using it to calculate percentages

Agree. MaxQuantity is an Optional&gtQuantity>

should quantity come before item name?

Should be address, not supplier

HAHA i think we should just commit on his behalf. it's a minor issue

@halcon-blanco as discussed in telegram, we should probably create a wrapper class so we can make use of polymorphism instead of using instanceof

But for now let's implement the rest on top of this first

Should it check for deliveryModel to be nonNull too?

@halcon-blanco i have a suggestion. We should make use of DeliveryCommand and ItemCommand abstract class to have a abstract method execute that takes in its respective model. This will adhere to OpenClosed principle better

I feel that similarly to the command Hisotry there should be a limit of how many times u can redo incase of memory overflow

Like limit the number of state stateList holds

In my experience with CommandHistory's previousCommand(), be wary of the corner case if suppose:

you have 2 states, state#1, state#2

undo() should return you to state#2 and not state#1.

Could you give that a shot? Maybe either via junit tests or manual testing

This is a complication from having the pointer pointing at the last element of the list

Nvm ignore me i've read through your implementation and realised its different

Perhaps instantiate arraylist with a initial capacity to optimize performance (remember from 2040s they taught us that arraylist copies over and doubles in size everytime its limit is hit)

Eg private static List&gtDeliveryBook> deliveryBookStateList = new ArrayList&gt>(MODEL_STATE_LIMIT);

and i feel that it shouldn't be a static variable simply because we may use different instantiation of deliverybooks in testing as well

i think a better condition would be canRedo() instead

having it as canRedo optimizes performance as we only really need to do a copy if there exist downstream "commits"

ArrayList.size() != Capacity btw @halcon-blanco

Thanks!!

shall merge into master first so others can work with new design prior to implementing undo/redo tests

Add

undoThenUndoThenRedo test

and

undoThenUndoThenRedoThenRedo test

maybe state what for!

same here

Yeap that sounds better! Made changes

just pushed! take a look

Fixed! thanks for pointing it out!

Same! Fixed

Take a look now! added comments

Fixed! take a look!

to adhere to similar level of abstraction in the code

Done! Take a look

o it's auto generated by intellj HAHA but i'll change it to match!

The method name would be misleading in my opinion

Attempting to do it now

Done! @halcon-blanco please check

@halcon-blanco did that! it turns out this helped iron out bugs so much thanks!

I changed it to updateItemListFilter!

Opps my bad! Thanks for pointing it out

Changed!

wednesday 16th September 2020 8pm start coding

@Wincenttjoi yeap that's the plan. it's in this week's tutorial submission

buggy PR

Highly likely it's because of preference.json as AB3 tries to read userpref before inputting default values for GUI

Would it be possible for it to bypass preferences.json by ignoring the presence of it instead of manually deleting the file?

@xnoobftw one way is to not put preferences.json inside gitignore, but this default value is meant for first time users. Since all of us are developers, its okay to delete it (because users perspective as first time users they will not have the preferences.json)

sounds good! LGTM

LGTM!

Hi @halcon-blanco could u comment out the failed test cases so i know which ones to work on + CI wont fail? Thanks!

@wengfaing btw have you fixed this in your add metric PR?

A delivery model requires name, phone, address and order. Is the PR meant to be complete or is it WIP? Just checking because I can't seem to find any of these in the PR

It's to be implemented by @zeranium97 when he implements storage

IMO having more space for delivery makes sense as it composes more information

Disagree. Different restaurants may use different kinds of metrics and having metrics follow enums we may not cover all cases. In such cases edit command would suffice to correct the error

You mean whether the search word is a substring of item?

could we implement that just for phone number and address?

Delivery order sounds good! We could potentially reuse Quantity from Items package

@halcon-blanco isit okay if u took this? Since you implemented find for delivery!!

Refer https://github.com/AY2021S1-CS2103T-T12-1/tp/commit/0f5717d4ac91e4074c182c77b4ffb670eb78f0fe

as discussed with @halcon-blanco , we feel that having a wrapper class that holds instantiation of both DeliveryModel and InventoryModel is better than having to use instanceof to check and having to overload the Command#execute method due to huge amount of repetition of code

Following the wrapper class idea adheres to SLAP principle more than the latter solution

@AY2021S1-CS2103T-T12-1/developers FYI

@xnoobftw If you are okay with implementing, I think it would be good to return a message on the commandbox to make it consistent with other commands

May i know what you mean by this?

@xnoobftw If you are okay with implementing, I think it would be good to return a message on the commandbox to make it consistent with other commands

May i know what you mean by this?

So an example would be after the command sort ... a line should return on the command box

A possible reply would be like: You inventory item/delivery is sorted according to .............

If i'm not wrong our agreement was that sorting will be done implicitly and does not require a sort command

Refer https://github.com/AY2021S1-CS2103T-T12-1/tp/commit/977699417b62170546c6bb6c477710e13d9b377b

Because there's alrdy one from AB3 and it's easier to refactor then to do from scratch

And I accidentally did it actually in my PR

HAHAHAHAH @halcon-blanco

@xnoobftw

do you want to add small note on ur diagram to briefly describe what XYZ is?

Arrow for &gt> Parser on the Parser section is abit misleading, mind to remedy that to make it more coherent?

Perhaps you can also bring the Command and Parser box bigger (filling up >80% of the space) bcs there's too much white space and its too small for people to see. Size of individual blue boxes can also increase in size if you dm 👍

Executes labelling on command part not clear on which line it should belong to

HelpCommandResult extends from CommandResult missing

I think there's no more concrete XYZCommand since they are all extracted to the smaller commands (items, delivery, help)

Sequence diagram for logic seems ok

Will do!
Do you mean having a solid line? Because it's how its represented in AB3
Do you mean increasing the font size?
The PUML auto generates this D:
Added! Thanks
Redo, Undo command still does! exit too

@xnoobftw try to occupy the diagram >80% of the picture! If not too small hahha.

Edit: I realized that we can't reposition the arrows, just saw the documentation hahah. Not sure if 2 is doable

Idt 2 and 3 is doable due to puml automating it

But does this fulfil ur requirement!

It's enabled

refer https://github.com/AY2021S1-CS2103T-T12-1/tp/commit/977699417b62170546c6bb6c477710e13d9b377b

Idt 2 and 3 is doable due to puml automating it

But does this fulfil ur requirement!

@xnoobftw

Can check this out for 3 https://plantuml.com/skinparam

Reason being is because we need to make our dg comprehensible thats why we shdn't just leave this out even though it seems trivial

Yup looks good! (Apart from box sizing)

Increased fontsizes to 30!

There's a couple of errors in the diagram! Check out the ss i tagged

And another update! I dont see a uniquetaglist class in the folder unless im mistaken! and i dont think we should show inventory book in the item class diagram

Remember multiplicity and deliverybookstorage is an interface!

Is there anyway to adjust so that the multiplicity is not blocked? Try increasing the lenght of the arrow

Change e to to another more descriptive name?

Similarly for this, change e to a more descriptive name.

change address to description

Should we remove all the tutorials?

change to package seedu.momentum.logic.commands;

Do we really need to store the entire project object in a timer?

Maybe we generate and use an unique project id?

calculate looks quite long, maybe you can abstract out some of the logic here?

I think the @param should end with a full stop.

The method is > 30 lines. I see you tried to reduce the length of the method with combinePredicates but I think you can abstract more of the logic.

Similarly, full stop for @param

Here also the full stop for @param

Maybe you can store "Kurz Elle Kunz" as a String variable since you used it more than once in this class?

Similarly for the starbucks elephant cats here

And friends owesMoney here

Similarly for "\\s+"

Similarly for "Alice Bob"

Store the array as a private static variable also?

Also for the "Alice Bob" in this class

Maybe change the getFormatted method in deadline to return no deadline set when there is no deadline instead so that a project does not have to know whether it has a deadline.

New line needed before @throws

Make name implement a comparable instead?

The method is quite long, maybe extract this into another method?

similarly for this

and this?

. for @params

Also for this

Empty @return

line before @param

fixed

I think 8 spaces not 4. Changed to 8 spaces.

Hmm I don't think is matters

Name is not optional right?

maybe just include as coming soon

Fixed

Hmm not sure

Changed to edit

Yeahh we should

Yupp

Not sure, but if we add a bunch examples, then a table would be like 1 line | a lot of lines

Fixed

This is to show deletion of a deadline so the deadline "created" is an empty one.

It's just the work of reformat code to align with the next @param

I'm not sure, both will have the same behaviour but its more of a parse error than unable to execute command error since it is related to validity, but this will make the overall design better?

I think the main reason to include check for created date is to ensure that we will never run into a utc offset problem, rather than making sure the deadline is actually after the created date and we are also not currently storing the created time. So I think its fine since only the created date is stored as long as the date of the deadline is later than created date we can just take it as valid.

Anyways I decided to change it

Time is compulsory for LocalDateTime in java.time so unless a dummy time is added in, LocalDateTime cannot be used.

I think it would be cumbersome to try to differentiate between the dummy time and the actual time if any. I think this mainly has to do with the backend part.

Then since the time and date is separated, it would easier to parse them separately.

I think I will create a general date superclass then make datetime, date and time inherit from it.

After checking the hierarchy of java.time, I realised the only common class ancestor of Date, Time and DateTime is java.lang.Object but they do implement similar interfaces. So I decided to make Date, Time and DateTime to implement a common Instance interface instead of a common class. And also if Date and Time inherit from the same class, it would imply that Date and Time is comparable.

I thought that this was the desired behaviour?

For 2 projects to be considered as duplicate, it needs to be created on the same date.

So no prefix will mean match any be default?

This is also used for Travel Plan name!

Name is also used by TravelPlan, not just TravelPlan object. Maybe we can add that in?

Maybe here can also implement Predicate&gtTravelPlan>, then we can overload the test method with test(TravelPlan tp) as well?

I meant implements Predicate&gtTravelPlanObject>, Predicate&gtTravelPlan> since a class can implement more than one interfaces.

As for this, 2 separate (overloaded) test methods:

public boolean test(TravelPlan travelPlan) and public boolean test(TravelPlanObject tpObject)

I think this should be return the Travelplanner?

What is the reason for this change? Previously I changed it to Graph so that it allows for names with some punctuations, such as "Alice's Home", i also tested it so it was working.

I see, then can change to "(\\p{Alnum}\\p{Graph}*\\p{Space}?)+" ? Because I have multiple test cases with names that includes punctuation.

Maybe can change to "The wishlist only stores activities, not accommodations or friends!". If not it sounds like the accommodations and friends of wishlist is empty.

Is this additional newline intentional? (There's two empty lines in a row)

Maybe can add a Javadoc comment here. "Takes the value -1 if no tab changes are required. Otherwise, represents the index of the tab to set the travelPlanObjectListPanel to."

Don't have to change now, but maybe we should store these constants under the respective classes (i.e. Activity, Accommodation and Friend class) as TPO_WORD, since we are referring to these strings in multiple other classes. Similar to COMMAND_WORD.

Class is missing JavaDoc. I'm not sure if this is allowed since it passes CI?

Class is missing JavaDoc here as well.

should we use {@code ParseException} here instead of seedu.address.logic.parser.exceptions.ParseException?

Missing JavaDoc for this method.

I think I added a space after Activities on purpose previously, so that the tabs are more spaced out.

Is this additional new line intentional? Sorry I'm abit OCD, can ignore if you are okay with it!

I think this part it's okay, since travelPlanObjectType for ShowCommand should not be -1. Maybe it would be clearer to throw this exception in the constructor instead of here. Same for the exception above.

The space supposed to be after though.. HAHA

Can use the {@code ParseException} syntax instead of just the string?

travelPLanObjectType spelt with capital L by accident I think. Same throughout this file.

Is the additional line here intentional?

Just clarifying here, what's there TODO here?

Can this be implemented in model instead? Then call the model method instead of accessing travelPlan methods here directly. Treat model as a facade.

Same comment as above! 😃

Yea yixian is right.... HAHA it's the name of the travelplans in the travelplanner panel

can use constants to name numbers?

Returns instead of Return? And not sure if there should be a full stop here.

Not sure if there should be a full stop here.

Should it be:

loops through the keywords (of type List&gtString>) and return true if there is any match with Nameable.getName().name

yeap! It's meant to be Jan, Feb, etc.

I did that at first, but it failed checkstyle because apparently abbreviations must be capitalised for the first letter only.

Just tested, the ListView implemented in TravelPlannerPanel implements scrolling already!

Same as above too!

Thanks! Updated accordingly.

Updated. Thanks!

We can typecast back to Travelplan to access AccommationList, if we are sure the directory is a travelplan.

I think this is still considered polymorphism though?

It's for testing purposes and to also remind programmers under what conditions this call should be made only. I wrote this with the intention that the programmer should only call setToAccommodationList() if the directory is a Travelplan. I was thinking about try catch, but it's not a scenario the user will face, since this should be configured by programmers (and should not happen because of user input/calls). It's also okay to write try catch, but there should not be any exception in the first place unless there is a bug in the program.

if want to check can use instanceof!

Thanks, updated!

Updated, thanks!

ok!

yeap! so commands must check the directory before setting accommodationlist etc, since commands will have to know the directory to execute local commands anyway.

This is to ensure the internalList does not hold the exact same copy of the TravelPlan.

Not too sure if this is okay, removing it resolves execute_validIndexFilteredList_success in DeleteFriendCommandTest

This is resolved in the most updated version of this PR.

Todo: Update to link to directory.

Small nit but will it be better to use the word patient here instead?

Hmm was wondering if IC here will now refer to INDEX instead as we adopted the new command syntax?

Perhaps we can consider including another section detailing our acceptance of natural date syntax above to provide users with a clearer understanding of our date syntax.

Yup! It looks great 😃

Hmm maybe you can consider updating this too as they will probably ask us to do it in the weeks ahead. But it's not essential for this iteration so no worries!

Yup I think he missed that out too, good spot @JinHao-L . Perhaps it'll be better to include a breakline after the "]" as well to separate the example from the format?

Oh and I think DATE can be an optional input here as well according to our user guide. Adding the link here for quick access 😃

https://ay2021s1-cs2103t-t12-4.github.io/tp/UserGuide.html#listing-upcoming-appointments-by-date--view

Hmm, as @YangYue128-helen mentioned, perhaps it'll be ok to leave out this check as we are able to support view commands without a DATE predicate as well?

Based on line 53 of ViewCommand.java, the current system seems to support the display of all future appointments if the predicate input is null (in the case that a date is not entered by the user) so I think you've got it covered @ZhangWanlin98 👍🏻

Oh wait after reviewing NuudleParser as mentioned by @JinHao-L , I think the check done here is actually valid as the ViewCommandParser is only instantiated if extra input by the user following the view command is detected. Hence, it actually indicates an invalid command format if PREFIX_DATE is empty as it would mean that something else is written.

Yeah I agree with @ZhangWanlin98 that it may be better to import the DateTimeLoader class directly to improve code readability and keep the variables used on the same level of abstraction.

Perhaps it will be better to phrase it in the following way Creates a DoneCommand to mark the specified appointment as done? Let me know what you think of this 😃

There seems to be some grammatical error here. It should be returns a DoneCommand object instead.

Think you missed out a "to" and full stop here. Perhaps it will be better to phrase it as if the user input does not conform to the expected format.

Hmm perhaps you're referring to {@code editedAppointment} here instead of editedPatient?

Perhaps the appointment should exist in the AppointmentBook instead of the PatientBook(formerly AddressBook)?

Hmm perhaps the ! on line 66 should be omitted as it looks like it’s throwing an exception for duplicated appointments when it detects non overlapping appts instead. Let me know what you think about this 👍

Nice catch 😉

Thanks for changing them to more applicable tags for our context!

Good catch!! And thanks for updating the user stories too 😄

Should PersonListPanel be PatientListPanel instead?

Hmm perhaps the phrase "mark appointments" and "feature" should be in lower case?

Perhaps you may consider the following phrase instead "Please refer to the following for an example usage scenario on how the mark as done mechanism works in each step:".

Let me know what you think! 😄

Maybe it'll improve the flow by replacing the phrase "As a last step" with "Lastly,".

Also, it seems to me that you missed out a "a" in "CommandResult with a SuccessMessage ".

Great job on the diagrams!! 😄

Hmm, perhaps all instances of "Person" should be changed to "Patient" for the diagrams.

Jin Hao's phrasing looks good to me too 👍🏻

Hmm, perhaps you can consider the following phrase instead, "books an appointment at 2am for the 1st patient in the list on the coming Sunday for a duration of 40 minutes.

Additionally, I think it'll be better if we use 2pm as an example instead cause 2am is in the middle of the night and outside the usual operating hours 😅

Same here for the am!

Would it be better if we phrase it as "(unit in minutes)" instead?

Excellent work on this 👍🏻

Good job considering all the cases 👍🏻

Thanks for pointing this out! I thought of this too but figured that it'll be better to change the package name in a separate PR as the current one only focusses on refactoring the AddressBook class. It will be easier for version control as well.

Hmm I think it's more suitable to keep it as versionedPatientBook as the original extended AddressBook as well which does not handle appointments.

Oh yes great spot! I'll make the necessary changes, though I believe that applying trim on our argument input will have also removed the trailing whitespace.

Hmm I added the square brackets following the tutorial given in our textbook. I believe they added it in as entering an empty remark serves to remove an existing remark assigned to the same patient. Currently, nurses can use the remark command to both create new and modify existing remarks.

Will it be better to delegate this task to the edit command instead?

Oh I've done some tracing and found that IllegalValueException is normally used when your method is passed a wrong input.

In the case of parseIndex, a ParseException is thrown to represent the errors encountered when the input index isn't a valid number (i.e >0) or is a letter.

However, since ParseException extends IllegalValueException, using IllegalValueException in this catch block will allow us to catch various kinds of ParseException should we decide to extend the functionality of our code in the future since it's the parent class.

Hmm makes sense, alright I'll change it over to ParseException! Figured otherwise at first as the tutorial employed the use of IllegalValueException as well.

Personally, I think it'll be a good addition to have this enhancement for our future iterations as it may seem like a bug if we are able to cancel an appointment that happened in the past. However, I realized that it shouldn't be the case for done since we will only mark an appointment as completed after it has occurred. Thanks for pointing it out Jin Hao 😃

Would love to hear from the rest too!

Yup I left it there as a placeholder as I'm still wondering if there are any forms an Invalid Remark can take. Any thoughts on this Jin Hao?

Nice catch! Thanks for spotting this 😄

Yup I agree with you too Wanlin.

Changed it! 👍🏻

Yea good point! I'm able to limit the number of characters a user can add for a remark. However, I think the challenge with doing this may be the need to display the number of characters remaining(while the user is typing?) as it'll be hard for the user to manually count the number of characters added.

Thanks for spotting this 😉

HAHA thanks bro 😃

Yeah I agree with Wanlin on the abstraction part but I can also see the point about consistency. Hmm, I'll change it to match the style used in the rest of the files instead 👍🏻

Thanks for spotting this! Missed this out when I was editing it 😄

👍🏻

oh yea nice spot 👍🏻

HAHA thanks 😃

Oh yea!! Nice catch thanks 😄

As a nurse, I can easily check the patient’s drug allergy history so that I can double-check if the medicines prescribed are not in the list.

Hey Jin Hao, thank you so much for pointing out the error!

I've been meaning to consult the team prior to seeing your comment. The links you provided were really helpful to the resolution of the test errors I encountered. Alternatively, I have updated the settings in my IntelliJ to resolve the issue. You can check out the following link for the alternative strategy I employed.

https://www.jetbrains.com/help/idea/configuring-line-endings-and-line-separators.html

LGTM 👍🏻

Duplicated issue. (#72)

Thanks @JinHao-L , currently working on the changes!

Fixed checkstyle, added and modified existing tests to support the addition of Nric.

Thanks for checking it out Jin Hao and Wanlin 👍🏻

Thanks Yang Yue and Jin Hao!! Originally planned to add the test files in a separate PR haha. Am working on them now 👍🏻

TaskTemplate instead of Task Template/Preset Task Template

Should Preset Task just be Task only?

For now maybe we should use remove the spacing between Task Template, Task Schedule, Module Schedule etc.

Probably should try to use module code instead of index

modules*

has to be an integer from 1-7*

has to be a valid positive integer. The Total number of weeks are calculated using the start and end date of the semester*

weeks*

has been completed*

Displays all tasks in the week that is specified by the user

has to be a valid positive integer. The total number of weeks are calculated using the start and end date of the semester.

Total weeks in the semester

Creates a template of tasks for the user to reuse weekly to quickly add into his/her schedule

List all task templates that were created

Creates and adds a preset task in the selected task template

has to be an integer from 1-7, 1 being Monday and 7 being Sunday

Clear all preset tasks in the selected task template

Rmb to change the capitalisation for UG

Maybe listtemplatetasks would be a beteter name

List all preset tasks in the task template

Maybe listallmodules will be a better name

Ternary ? should hour instead of hours

Should name the class name as Day.java

Refactor Days to Day

Some have full stops and some don't

Can consider using the Amount class so Price will store an Amount instead of a big decimal

😸

Can check out Hans implementation for the clear command that that passes a new service manager (expensetracker for your case)

Message takes a bit of time to understand for me, maybe undo success or undo complete is sufficient 😸

Same here, maybe "Already at oldest change" (copied from vscode vim)

Yup its quite referenced from the original AB3 tests

Thx for the catch! Removed them 😄

Thanks for the catch 😃

Better to merge this after everyone updates their profile in the aboutus page

Amend commit to update DG use cases with suggestions from @khoongwk

Not sure if add remark changes were accidental for this branch but would be useful to have it to serve as the description for tasks 😸

LGTM

Added some tests

Consider checking out Galvin's implementation for parse method of find command

Current implementation is just to take total revenue for the month subract with total expense for the month. Tests not added yet

Should we use Index to select the book instead of the name of the book? Since the delete command already makes use of Index and using bookname is quite prone to typos

The user guide link is wrong, the correct link should be https://ay2021s1-cs2103t-f13-2.github.io/tp/UserGuide.html

Same for the dev guide as well, correct link should be https://ay2021s1-cs2103t-f13-2.github.io/tp/DeveloperGuide.html

I think you may have missed out on this part. The View command is meant to view detailed info regarding a single book.

I think this extension 2a isn't supposed to be here anymore, its included in UC05 already.

Just saw that the extension numbering here is incorrect, should be 2a, 2a1, 2b etc. Can you help change them too 🙏 thanks!

According to the user guide, the prefix should be "tp/" for total pages and "b/" for bookmark for consistency purposes right? Maybe we can discuss this further!

Thanks for doing the renaming! There's some parts which haven't been renamed such as the Javadoc here, comments in the equals() test as well as here: https://github.com/AY2021S1-CS2103T-F13-2/tp/blob/c568a3c5177c68a33c3e6279923fa8f3c0356df0/src/test/java/seedu/bookmark/logic/commands/AddCommandTest.java#L153

Would be great if you could change those too, thanks!

Could you edit the javadoc and comments as well please, thanks!

I think this line can be removed since the tests have been updated.

Could you update the tests names as well

I think there's a typo here, should be viewFirstCommand and viewSecondCommand right?

Perhaps you could include a super simple javadoc for this class?

The jdoc here should be "Add a note to a book" or something along those lines right?

There doesnt seem to be any usage of editBookDescriptor in this method

Is this bookmark validity check necessary? since this command doesn't touch the bookmark field at all

Left-over jdoc from the EditCommandParser. Same issue for the parse method as well

Left-over jdoc from JsonAdaptedTag. Same issue in the toModelType method

Not sure if this jdoc is accurate?

Should we allow more than alphanumeric characters? I think users would want to use punctuation when writing down their thoughts on the book.

Also I think it would be good to put in some length limit for the title and text as well. I don't think the application would be able to handle displaying text that is for example, 10,000 words long well. Perhaps something like 120 characters for the title and 1000 characters for the text?

Thanks for writing such comprehensive tests and increasing our code cov hehe 😄

Would have to take a look at your implementation to confirm, but I don't think that "algorithms" constitute a component on its own. Could they just be part of the Logic component given that the algorithms are used to perform business logic?

Did you mean "will be called" rather than "will be implemented"?

Need a space between #### and Implementation

This could potentially cause a NPE if the .get() returns null. Maybe you can follow the same style as the other fields: have a static parseGoal() method in ParserUtil that does the validation checks, also making use of the isValidGoal() method in Goal.

Maybe put a requireNonNull check here just to be defensive?

Typo here? should be AddNoteCommand right

This could be slightly misleading since its not always 3 words anymore. Perhaps just "Find words" would suffice

Instead of having all these methods being abstract, they can actually just be implemented inside WordStore itself and inherited by each of your different types of WordStores (TagWordStore, NameWordStore, etc). Currently, there is a lot of repetition since each of the individual types of WordStores implement their own addWords(), deleteWords(), etc but their logic is exactly the same.

Maybe use a HashMap or HashSet for O(1) look ups?

Good suggestion! I've made the necessary changes

Thanks for spotting the mistake! I've made the necessary changes

Yea it looked quite iffy to me too but didn't know how to phrase it nicely. Thanks for the suggestion will improve it!

LGTM

@mgiang2015 you uploaded your photo in the wrong folder, it should be uploaded in docs/images. Please open another PR to close this issue! 🙏

LGTM!

LGTM

Closed by #63

Reopening as @mgiang2015 's part on user stories for the View command is not done yet

Closed by PR #88

Closed by #90

I don't think we can change the copyright license?

Abit hard to look through all without stepping through 😕

Was thinking of letting it merge and we test; but see the rest

NonExistenceFile.json is assertFalse for every src/test/data/* folder.

I guess it is a bug output file since the test doesn't want it to exist.

to fix this issue (change Clients to client), refer to the new comment

From what I found out:

The program uses the "Clients" variable as keyword to save a json file.
The program then uses @JsonProperty("clients") to pick this keyword for assignment from the json file

change @JsonProperty("Clients") to @JsonProperty("clients")

Yes. I expect it to have more errors.

Because, the actual data file is saved as caps Client instead of client.

I can only help u find these (those files in /JsonAddressBookStorageTest & /JsonSeralizedAddressBookTest) files, that you might be likely to change them from caps C to small C. Maybe there are others that are not flagged out

I think we should merge with the 2 test failure and create a new issue tracker to debug. Then can find out the root cause and more people can debug it instead of predicting the problem.

It seems to happen during the execution of saving a new temp file + reading failure.

This will allow the user to start and end with '-'

Not sure if that was intended.

If it was correct, try to add 1 test case to test it 😄

My DateTime formatter also different from yours

DateTimeFormatter.ofPattern("dd/MM/yyyy HHmm")

Maybe can do if (sessionId == null || !ParserUtil.tryParseInt(sessionId)) , then throw IllegalValueExcep

Best to undo this. Dont put your name in git blame

Why suppress checkstyle warning though

Help to remove empty else

Do remember to add this into AddressBookParserTest also.

Return a list of ??

Uses*

@return A list of clients

@return A list of session

Sorts*

Remove dead codes

Remove //placeholder as it is live date/time

" sview p/all" will not update the label

commandResult.equals(ViewSessionCommand.MESSAGE_SHOW_SESSIONS_SUCCESS will always return false because commandResult is a type of CommandResult and ViewSessionCommand.MESSAGE_SHOW_SESSIONS_SUCCESS is a type of String

Try to remove debug statement before merging

System.out.println(commandResult.getFeedbackToUser());

(e.g. If today is Friday, display from today till the Friday that falls 2 weeks later).

In other words, it will display today + 2 weeks (14 days) in the future

in the result of the **c**find command

clist

to force delete a client ...

need to add hyperlink to #sview before deleting

Want to update to this?

clist exist in 201-208

The &gttitle> will set it as tab name, while the # About Us is the in the webpage.

Yes. I agree with you, but UI cannot run test cases.

Putting it in ViewClientCommand cannot test execute.

Usually, it should be placed in MainWindow::executeCommand, but I will see how

Edit: ViewClientCommand will create a lambda runnable for MainWindow to run.

Updated

It is a quick fix for AutoComplete. So without it, we must find the cause of why the first row was different colouring

fixes #18

similar to #41

@tanweijie123 will this change be compatible with the change you proposed for #68 ?

Yes. All the test case refactoring can be used. (because I have not started with that)

Gym, Interval, ExerciseType can be imported because currently, I am using it as String type

We can merge the Session to accommodate with ^.

Can refer to #70

#68

fixes #78

Right sidebar previously had a scrollbar that doesn't show now, but I think it's fine not to have it. Lgtm!

Vbox have auto hide scrollbar if not necessary. So maybe your screen size bigger?

Have we checked with Prof Damith on using controlsfx as external libraries?

Yup. Approved.

https://github.com/nus-cs2103-AY2021S1/forum/issues/308

Updates: The UI is already available on the homepage. We just need to change the listview to display only today's schedule instead of the whole schedule list

To add this highlighted line to fix the bug

Will push it with some other PR next time

Today's schedule's list not correct lehh

Before:

After:

I think this should be Warehouse's remark 😃

Since we are including this constraint, should we include this inside our user guide so that users will be aware of this constraint when adding remarks to a warehouse?

Should this be Remark instead of Address? Noticed this issue in a few places below (email instead of remark, etc) as well for Javadocs of various methods. Do take a look at it 😃

Do you think replaceWarehouseList would be clearer here since the above method to change one warehouse differ only by a single letter? 😃

Should this be removed instead? 🤔

Minor issue, missing '.' for isSameWarehouse

Should we include warehouse here although for this iteration we are not intending to include tagging for warehouses products?

With the if condition statement removed here, will there be an issue where the for loop only runs one time since the return statement will force the function to stop executing?

Same issue here, as pointed out above.

Is the extra supplierList here as a placeholder for warehouse? I think the statusbarPlaceholder should be removed as well 😃

Just adding a note here to remember to change supplier to warehouse when updating tests cases later on.

Just to check, did you perhaps miss out the conflict here?

Same for these conflicted import statements as well 😃

Just wish to clarify, is the method empty because this method is allowed to be called but there is no specific function this method can do?

Alright, noted

Will it be clearer if the statement is Creates an Addcommand to add the {@code Product} to the specified {@code Supplier}

Maybe it will be clearer if you clarify that the exception is thrown due to index specified to be larger than list of supplier/warehouse since it is not so clear reading from these lines here 😃

Just to clarify will this still be relevant for CLI-nic and also, is it still Tag, or would it be Remarks?

do remember to update the delete command here as well 😃

Are suppliers and warehouses missing Remark attribute?

I see! Agreed, I think we can improve on this paragraph after we finalise our UML towards the end. Looks good to merge then! 👍

Yes, sorry about that!

Just wish to clarify, is there a need for the if clause here since there is a conditional check above (lines 89-90) where this method would be called if targetType.equals(SUPPLIER). Could there potentially be any cases where targetType is not equals to SUPPLIER and this method could be invoked?

Just to clarify, what are the other same methods that you are looking at to shift it under Command class? 😃

Ah okay, that explains! 😃 All is clear now, no issues with this part 👍

Hmm, I am not sure if shifting to the parent command class would be okay, since AddCommandParser only implements a Parser interface and there is no parent class for the parser classes. Though I can also understand where you are coming from as well, I am thinking would it be out of place if we shift it to under ParserUtil class? Maybe we can discuss with others as well and see how do we want to implement it such that there would not be a case of overlapping.

Not too sure if it makes a major difference, but I am wondering if it would be better to access the fullName via some form of getter method instead of accessing the attributes directly. 🤔

I think this empty line can be removed

Some extra spaces here can be removed as well

Hmm, I guess in that case let's just use .fullname instead of a getter method then, since it is used in several places as well 😃

Accepted, will remove @return and change "Creates" in first line of JavaDocs to "Returns"

Thanks for pointing that out, will push another commit to fix this!

Noted, thanks for pointing that out! Will be pushing another commit with the updates.

Thanks for pointing this out, missed out on the javadocs comment for class!

Noted, will updated in next commit as well.

Thanks for the suggestion, let me try to use that instead of arrays.aslist(String[]{})

Thanks for pointing that out! Will be removing that in the next commit.

Thanks for pointing this out, will fix it in the next commit along with removal of above clause as well!

Thanks for pointing this out, will fix it in the next commit!

Oh no, this should be clinic instead. Thanks for pointing this out!

Oh the error message will be shown when a user tries to use a supplier prefix, s/ when editing warehouses, I think that the output message is correct though? 🤔

Thanks for pointing them out! And yes, I think I made a typo on the 4th sentence, will change it to "will be used to process user input"

I think I figured out why, there was not space between the last line of the paragraph and the line right after it (with -), will fix this in my next commit!

Will also fix the grammar as well, thanks for pointing that out.

Accepted suggestions above, will do the appropriate changes

Thanks for pointing them out! I agree with Jeffrey on the third point as well, I think it would improve user experience if we let for instance a delete command with random string at the back to pass through rather than forcing the user to re-enter the command without the random string.

As for the first point, may I clarify if you meant for e.g. add vs Add (or any other variations of add) in the case of command string to be insensitive?

Also, another bug I noticed was for delete, find and view, the ordering of arguments matter. In our user guide, it was mentioned that parameters can be in any order. However, without any delimiter in place, like t/TYPE, it will be hard for us to ascertain which word is for type and which word is for name of supplier/warehouses (in the case of find and view). I was thinking if we should specify that ordering does not matter for all commands except delete, find and view in our user guide to be clear.

EDIT:

Just to add on, the current way of handling adding of suppliers and warehouses has a bug since type of determined by doing a substring of trimmed arguments. If users are allowed to reorder the arguments, the parser will detect this as an invalid command.

In addition for adding of supplier, it seems like email address has to be a compulsory field (invalid command is shown), but in the UG it is an optional field. Should we still keep email address field as an optional field?

For adding of warehouses, if remarks field (which is optional) is left out, a java.lang.reflect.InvocationTargetException will be thrown. I think we missed out these cases, but no worries, let's fix them in v1.3 iteration! 😃

Commenting for future reference:

we will probably need to change these kind of files with traces of address book in it. No need to change for now.

Need to change JsonSerializableAddressBook class name to JsonSerializableEvaStorage

Minor comment, but maybe it could be private instead of protected? Since we would just use getter methods to access these fields.

Perhaps we can make use of the regex method used by the other classes in model? In this case the validation format would be "^(3[01]|[12][0-9]|0[1-9])/(1[0-2]|0[1-9])/[0-9]{4}$" for dd/mm/yyyy. I believe it would make our code seem more in line with the existing code from AB-3.

Maybe interviewDate shouldnt be in an optional wrapper in the constructor in case it errors? We could include a try catch then or we could simply make a getter method for interviewDate that returns an optional&gtInterviewDate> and set up the error handling there.

Agree with Royce. Maybe we can use an enum or separate class for this as well.

Good use of existing functions.

Same goes for these. Don't think it should be protected.

Not sure if it's ok to delete the person database. If we can do so without the application collapsing we should remove it if it is redundant! (of course this means updating all the tests) KIV

@code applicant, address book -> eva storage

the word "address book" appears multiple times in javadocs at multiple places

not sure if we wanna change it to editedApplicant, editedStaff. Can choose to change or not up to u

May wanna change the way interview dates are represented. (I think this is for Nikhila?)

isn't this method in parserutil?

maybe instead of coming up with a myriad of prefixes when we make a new command like ls, le, id, we can standardize a date input to always just use PREFIX_DATE which is d: or d/ or something along these lines?

maybe we can use an enum for this

The extra tag added here should be Applicant instead of staff

Applicant instead of staff

We can remove the leaves flowpane as applicants do not have leaves

Applicant

edit the logging as well. I think staff list panel should have the same problem.

I think most of the javadocs in the new classes have yet to be updated

I guess we need to implement window/tab switching

Perhaps a better way to process statuses from strings would be to use the 'valueOf' function of enums. i.e

'PossibleApplicationStatus.valueOf(status.toUpperCase()); //throws Illegal argument exception if its not a valid enum

not really sure if it can be applied here as you would have to try catch either here or whatever is calling the constructor.

with relation to my previous comment, this can be removed i think but im not sure how the constructors and the enums tagged to strings work.

perhaps we can abstract this out to dateutil? If the current method doesnt suit what you need you can create another method and another datetimeformatter to suit what you need

maybe you can make use of the method arePrefixesPresent in parserutil

i think we need to find a better way to handle this. I will come up with a app wide state to monitor what we are currently looking at so the commands dont mess up.

same as DeleteCommandParser

take this out if not the app wont start lol

I believe a better comparison would be between Leave and Address or Tag! Leave should handled the same way as how an attribute of the person is handled instead of being handled the same way as the Person itself. But you are right, I can have the parsing method imported from dateUtil to achieve better abstraction.

LGTM!

Done for week 6 tutorial, not needed to merge

Not needed to merge

Looks good maybe you can do x.

LGTM

LGTM!

Closed. refer to PR #62 for updated version

LGTM. However due to dependence on filteredStaffList, we will need to change the find function in the future.

As a HR manager, I want to be able to add comments on staff so that I don't have to do it physically and can have the data stored in one location.

basic functionality implemented in v1.2. Functionalities stated in this story will be added in v1.3

LGTM

LGTM. Thanks for correcting this small error!

I think we can close this PR for now. Can open again if needed.

LGTM

Slightly confused why the need to update the prevous code base person model. Is it failing checkstyle?

Change to Tests to follow the rest of the jdoc comments.

Could add constructor tests eg: Referencing from person/AddressTest, as constructor has requireAllNonNull similar to person.Address

This could be applied to a lot of previously seen files.

Something like this is possible:


    

    @Test

    public void constructor_null_throwsNullPointerException() {

        assertThrows(NullPointerException.class, () -> new Location(null));

    }

    

    @Test

    public void constructor_invalidAddress_throwsIllegalArgumentException() {

        String invalidLocation = "";

        assertThrows(IllegalArgumentException.class, () -> new Location(invalidLocation));

    }

    /**

Add null location test, referencing: UniquePersonListTest.contains_nullPerson_throwsNullPointerException()

Similar as first comment about Tests that -issue-

Same as abv

Slight complaint but could add line comments on what exact part of equality is being tested in each assert as it was done in some other class equality testcases

On further review, this addition would be a big increase in requirements for testcasing and is not suitable for a small modification to a completed pull request.

We should open a new issue about this on refactoring and improving testcase coverage on Constructors and Null Checks.

Perhaps some jdocs here would be good to ensure readability of code

Jdocs

Maybe should have a MESSAGE_USAGE string like if someone does sth like

listi jkdnkjvsdsn

or something ( unsure if will return error here)

Constructs ...

May not be in line with good OOP practices. Consider alternative representation or if it is not the proper namespace usage, amend

Bit more spacing would be good to have and perhaps line commets

Same as abv

We are replacing this with parser level specific methods?

how about item name etc

Or issit gonna use RegEx instead?

could probably rename -> inventoryinator.png

or something like that, to remove any reference to ab3

Im not so certain that getFilteredItemList is the only list we need for a ModelStub

How about the recipe list or location list?

bit of white space please 😃

spacing

Minor observation but item stores as a list, so why are we using hashset in itemBuilder?

Perhaps could add a class header for completeness sake, it is a public class

Slight nitpick but

Could probably use a Static constant predefined in the util files rather than a "magic string"

Command Word is removed at this step, the input that is recieved by parser is -n banana -q 50

Command Result is Returned and parsed to the UI i think So its not destroyed

&gtimg width="854" alt="Screenshot 2020-10-19 at 9 00 17 AM" src="https://user-images.githubusercontent.com/35429757/96390978-a5b3ac80-11e9-11eb-9fea-a92b866ef24f.png">

EditItem Command should also probably be destroyed after CommandResult is returned.

AddQuantityToItemCommand should also similarly be destroyed.

be careful what you wish for 😃

adding these lines back cause checkstyle to fail somehow?

Will not touch. should be handled by #20

Inventory is meant to refer to entire state of the inventoryinator. will add term to glossary

Oops :p lmao

Not known how implementation will be done, hence maintaining similar format as prior implementation for now.

Oof

this is intentional to show user that comma spacing is irrelevent.

User Guide is done for now.

From commit 9b2ccce:

In process of Unittesting, dificulty was encountered from utilising

testing utilities of original code base.

Specifically the assertCommandSuccess testutil method, relies on the .equals

of model manager, and model manager equality has null values initialised for AB3

and Inventoryinator versions, which if implemented to check, cause testcase

failures in stubs.

Recommended to perform refactor to code base and remove ab3 artifacts, for more effective

testing.

Will open new issue based on this finding.

Related to

#20

whats this print statement for?

should this be addTotalCalorieOutput? just like the addTotalCalorieInput() haha

How come this is date? should be calorieManager right?

the Date.MESSAGE_CONSTRAINTS

the javadoc comment should be calorieManager object right? instead of day object

the p want to make it capital P? HAHHAAH

comments should be Name instead of Food

test name should be name instead of food

I dont think license need to change haha

how come this one got 2 optionals

here also

this one also shd be myfitnessbuddy

here also

here also haha

here is myfitnessbuddy also right?

shd this file be deleted? already got the MyFitnessBuddyPerser liao

myfitnessbuddy?

here also haha

myFitnessBuddyFilePath

myFitnessBuddy

here also haha

here

delete this?

oh ya

done

Should we keep this?

maybe, coming in mid-v1.2? 😄

Don't remove this part. It is used by Jekyll

Perhaps, if you add this then we will have double title on the page (?)

Is this more of a "List a Client" use case?


2.  FitEgo adds the Client

I'm not too sure if there is a timestamp in the status bar 😅 , but it is also in the AB3 DG ...


      Expected: First contact is added to the list. Details of the added contact shown in the status message. Timestamp in the status bar is updated.


2.  FitEgo displays the client's whose name matches the keyword or text.

I see similar issues in other place as well

Perhaps its better to move this to ViewClientCommand::execute?

as to maintain separation between Ui and Logic components?

I agree with Dhafin.

i think in a javascript world, it is called a callback.

Perhaps hasCallback and getCallback is a better name?

Sounds good!

[open for discussion] Is it better to do the new way or the previous way?

This change is related to changes in SessionBuilder::withInterval

cc @maguireong @dhafinrazaq

hmm, what happens if we remove !important here? 🤔

Sorting session by its natural order is from the oldest (?)

Iirc, we are not using idCounter anymore for sessions

Perhaps its better to just delete this and add a reminder in the issue, I think

Seems like there's no change to AddSessionCommand?

Is it possible to just merge this together with the getTypicalAddressBook and getTypicalSessions?

Forget to change 😄

Repetition of line 151

Is it better to just have one function String getFormattedStartDateTime (DateTimeFormatter formatter) ?

ook 👍

ook!

Yup for consistency, we just put anything optional inside the descriptor

typo - add commands

it's changed from editschedule -> schedit

I think it is better to not have else after a return statement. It is following Make the happy path prominent

agreed. based on our discussion in telegram, the docs should document this.

Oh okay, i think I'll change it to only allow for the case where

cannot start or end with -
allow multiple - usecases

Oh right, I'll make it private

should we?

I think it is better to keep the structure of AB3 UG for future reference

donee

Proposed changes: show the number of clients inside the UI

TODO:

Repurpose the tag to history of injury / allergies
Change test data to medical names

Done for v1.1. Closing..

@dhafinrazaq @maguireong can help to look at it?

@tanweijie123 will this change be compatible with the change you proposed for #68 ?

Btw, perhaps it is better to test for checkstyle locally before pushing?

To run checkstyle and test cases, run ./gradlew check from Intellij terminal

To edit your last commit (so as to clutter the commit history), do git commit --amend --no-edit (also in terminal)

Yes, I propose this implementation:

sdel INDEX : will delete only if there is no schedule tied to that session
sdel INDEX f/ true: will force delete all schedule tied to that session and the session itself.

Implementation:

Will look for all schedules tied to the corresponding session before deleting the session

If i read it correctly, changes to existing classes is to enable comparing sorting clients (compared by name) and sessions (compared by interval start time) right?

Have we checked with Prof Damith on using controlsfx as external libraries?

Should we close this issue then?

Closing to wrap up 1.2.. Will create issues for point 1 (#115 , #90 )

We can implement this as a remark inside Schedule.

The remark is for the fitness instructor to add in comments and/or types of exercises done by this client.

We can then display it as part of the client's information

it should just delete the associated schedule I think ...

Please help me check if this class diagram is correct 😃

current implementation only check for invalid duration ( &gt 0 ), but don't have upper limit yet

@dhafinrazaq , you have added right?

should be fixed now ..

Should there be a new line between 1a and 1a1? This is also applicable to line 334 and 335.

Should there be an indication of the next step for the use case?

Should the block and room number be separated? e.g. b/BLOCK r/ROOM_NUMBER

It would be easier for the user to type without the formatting error.

This part perhaps can declare it as MESSAGE_USAGE in the ExportCommand?

So, it follows the current exception handling approach.

Can refer to AddCommand and AddCommandParser.

Perhaps can replace 1 and 2 with named constant to improve the readability?

Omit this blank line?

handleEmail and handlePhone both need to create the file and get the person list first.

Can consider declaring a method to do this part, then pass the person list to handleEmail and handlePhone.

The difference is minor, mainly to reduce the repeated codes.

Perhaps can include the capitalized email and phone to show it is case insensitive?

Does it need to include the COMMAND_WORD 'export' for the second argument of assertParseSuccess? As assertParseSuccess from XYZCommandParserTest does not include the COMMAND_WORD.

Should export email phone and export phone email be parsed successfully?

Good test cases to check the feedback message.

Can consider checking whether the output file contains the correct exported information (email, phone).

I just realised MESSAGE_USAGE of ExportCommand contains 'Invalid command format!\n' message, it should just contain the usage message similar to the MESSAGE_USAGE from other XYZCommand, so it will follow the current AB3 convention.

Can refer to the AddCommand.

Should parse method handle exception related to the invalid command format? As ExportCommandParser parses the command.

Good job in comparing the output file with the correct output file.

Are the println and lineNum for debugging? Can return areEqual.

I added the comment for handling invalid command format in ExportCommandParser.

Perhaps can consider adding test case for it.

Oh I mean the PR review comment for ExportCommandParser.

"Should parse method handle exception related to the invalid command format? As ExportCommandParser parses the command."

If you throw ParseException in ExportCommandParser, then perhaps can add parse_invalidArgs test case?

Perhaps can declare MIN, MAX_FLOOR_NUMBER and MIN, MAX_ROOM_NUMBER as a static variable and use it to validate room and floor? It may be clearer and more readable.

Perhaps can declare MIN, MAX_FLOOR_NUMBER and MIN, MAX_ROOM_NUMBER as a static variable and include it in the MESSAGE_CONSTRAINTS?

Should setBlockPref and setRoomPref be handled in ModelManager to follow the separation of concerns principle? As ModelManager handles Model related functions.

Move this method to UserPrefs as it is more related to it? E.g. setGuiSettings in UserPrefs

Okay, I see what you are coming from. As storage.readAddressBook() reads addressbook.json and converts JsonAdapterPerson to Person, it will do the validation check for every Person field.

Do remember to update JsonAdapterPerson#toModelType() to do a null and validation check for Block and Room before declaring it.

Perhaps String[] will be more suitable for blockSettings instead of String?

And roomSettings with 420 is quite confusing, can consider breakdown to min, max floor and room number.

Should blockPref be derived from UserPrefs#getBlockSettings()?

Can consider adding set MIN_FLOOR_NUMBER and MIN_ROOM_NUMBER, e.g. level 1 is the common lounge.

Okay, noted.

Change to camelCase for not constant variables?

Oh, I refer to JsonAdaptedPerson#toModelType method. The current convention will do a null and validation check for every field before converting the JsonAdapterPerson to Person.

There is missing of null and validation check for block and room String.

Fixed, thanks.

Yes, I forget about it, thanks 👍

Good catch, will update it.

Yes, will remove it, thanks for discovering it 👍

Yes, I should add that step. Thanks.

I was thinking about not writing it too. I will remove this then.

Noted, thanks.

Yes, accidentally typed "studyGroup".

Good point, will update it.

Update command summary and change 'person' to 'resident' in the User Guide.

Need to confirm about the CLI syntax for block and room number (combine together or separate).

Update the CLI syntax for room number. r/ROOM_NUMBER

E.g. r/B402

Might want to take in the user input and array of prefix, and store it as a instance variable.

No parameters needed, use the instance variable values, SLAP.

change to private

change to prefix

change to private, and change the name of the method, very similar to the one below

change to private, change the name.

Pull it out as a separate class.

SLAP, Abstract out the new ContactList creation.

Wrong object used, should be ResultCommand

Why need isSameContact method and the overwritten equals method?

Is it cos in the event of 2 differnet person with the exact same name?

Should it be final? Might be hard to keep updating right?

Will it work? Since this.contacts is final.

Same thing, contacts is final, im not sure if you can just set it.

Follow SLAP, bring out the remove function call.

Might want to pull this out into a new class for common usage. As I foresee we will be using this for some of the other classes as well.

If it is an empty constructor, should we just not write the constructor?

What is this block for? Don't think i rmb seeing this kind of code declaration hahha.

What is this function call? Why is it needed? Since this() calls the empty constructor that does nothing.

Might want to match the aligning of the dots, looks neater.

Don't use magic numbers, declare 30 as a constant in the field, and name it the word limit or something. This makes it more readable.

Why does this work? Since the field internalList is private, how can u just compare using .internalList

I think the prefix should just be called g/, as Im assuming that we add the "addgrade" command in front, so no need to specify the "a" in the prefix.

I thought we decided on using an association class instead? Im not too sure also. KIV

Why is it OR? So this means that as long as either the email or telegram plus the name is the same. Then the contact is considered to be the same? Shouldn't it be all 3 the same, then its the same?

I think we should split this into 2 test, one for passing and one for failing. I think i read this in the textbook before. Quite recently. Can check again thanks.

I will fix in the latest update!

Ok noted.

OK roger, will do boss!

If we leave the instantiating of the 3 parsers in the constructor, then each time a command called by the user, we are re-creating a parser each time. And not reusing them, which i think is wrong.

See above point.

but if we use .equals(), we need to check every single existing command, which is alot.

Looks good to merge, just file renaming.

Unused PR, delete if possible. Did not merge!

Achieved

If I'm not wrong the textbook didn't have these white spaces.

Same problem as above.

Can delete white space, seems unnecessary.

Delete this line, I think its from a merge conflict.

Delete this single white space.

Good that you have a separate class for Description, instead of a String.

Good that you have a Predicate class

Maybe, abstract away details, for better readability.

Can you just combine the two methods, seems like not much of a difference.

Abstract away to reduce complicated expressions

Do you want to have this as a separate constructor instead. So you would have Room(int roomNumber, Patient patient) and Room(int roomNumber, Patient patient, TaskList taskList).

Good for changing the toString method accordingly.

Good for changing the equals method.

We rearrange later in alphabetical order

Can rename it into parseCommand_deletePatient_success() instead?

Same here?

Use the model.displayAllRoom() for the time being. This part is in code quality and to be done in v1.3.

This will result in some problem of some Room UI, leave it as logic.getDisplayRoomList().

Instead use, model.displayFindRoom(room); where room is the room you wish to display. This is to prevent other workings of UI to not work.

Not necessary would affect UI for Room command and test cases.

"There are no rooms in the app yet, please define the # of rooms using initRooms (int) command."

Maybe can change to the above?

May be it is better to create a Name field?

To be done later.

Maybe can include the predicate in a different method like:

private Predicate&gtRoom> getPredicateForSearchRoom(int roomNumberExpected) {

       Predicate&gtRoom> predicateForSearchRoom = room1 -> room1.getRoomNumber() == roomNumberExpected;

       return predicateForSearchRoom;

}

That is wat I meant.

Now that it has been finalised, maybe you want to implement it?

Maybe want to change to TaskParserUtil instead of ParseUtil.

Maybe can include space between method and javaDoc to see better

Okay I will change accordingly!

Hi, yes that's why I thought a PriorityQueue would lead to an easier implementation as we can determine its priority in the Room class and we don't have to individually compare details. If you really want an arraylist I can change it though.

It is to add the number of rooms into the hotel

It is to check for the empty room with the least ID number. So the first room, is the least number that is not occupied.

Or if it is occupied then every room is occupied.

I thought of that, but why would anyone want to input a negative number?

Yes, it is for future person assigned to this task to complete it.

but it passed checkstyle

I just followed the name of files given above.

Okay

I dont get your problem here.

It wont because 1 and 3 are stored in the hard disk

I think you are confused because they are methods in different classes, just like the original code.

yeap, im not responsible for tasks and adding person

okay sure ill add it

I thought AddRoom would be better suited for adding person to room.

Same reason stated above.

I'll change it if you want.

I removed that field.

okay

Can you clarify?

Actually I no longer have this.

I see a lot of you have a lot of questions on PQ. I just thought that the comparison would be simpler as the priority is maintained by the PQ, and all we have to do is to poll and we dont have to compare a lot of variables so fewer bugs.

Yes

Okay, will add!

Okay

I need it for the Json.

Okay will do!

Okay

That was wat I was wondering too, but didn't want to delete before discussing.

Okay!

Okay I will change it.

Okay.

Okay

Okay will add, thanks for pointing out.

Okay

Okay, thanks for noticing.

Accidentally deleted.

Okay

Okay!

Okay

okay

Please don't merge even if there are 2 approvals. Thank you!

Typo on module

Change to "A contact can have multiple tags."

Can the usage of dots be consistent? Also, add articles (e.g. an assignment) and change 'the' to 'a'

Change to 'a user', 'the user', and 'opens'

No need to use 'the'

Erase 'the'

Should there be a space here?

Not a department

Shouldn't this be different department?

Not a department

Change to Information Systems

Not a department

Change to Information Systems

Lowercase D

Should this be duplicate modules?

Perhaps change to personsCs1101s to adhere to the coding standard?

Change naming to adhere to coding standard

I agree, might be mistaken for Name in Person

I think it is a good idea, it is more descriptive (and has the same format with ModuleName)

Sounds like a good idea

Shouldn't this be moduleCode?

Can change this to modules?

Does "This instructor is not assigned to this module" sound better? Also no need to use a dot.

The codeSet won't be changed (also followed the code from parseTags in the same file)

I was following the pattern from the other methods (contains, add, remove, etc), let me change the naming for those as well.

Maybe can add the person to be deleted is not found?

Same for accommodation and activity use cases also

So its not the command format but the error is missing person/accommodation/activity

Should we handle duplicate person/accommodation/activity when adding?

Need add use cases of edit function? Or too long already

Think the command is called 'show' instead?

I think can change address to location class? Since our user guide its location class. Can just import from activity.

Should be setAccommodation instead

Exception class shld be accommodation, same for the next one

unable to find specified accommodation

duplicate accommodation.

Should passport and mobile number be a data field since its a tag? Not compulsory for users to input.

If phone and passport is not identity fields, it shldnt be here alr

we shld restrict phone number to 8 digits for SG

Have to change regex already to maybe this d{8}?

can just initialise to private final Phone phone. Same for all classes. Just import the package at the start can alr

Same problem no need full package name

editedPerson change to editedFriend

Should change person to activity

Same

Wishlist

activities

Need add TravelPlanPanel, TravelPlanObjectListPanel?

DeleteCommandParser is Called WanderlustDeleteCommandParser for all

OK MY BAD

I think the accomodation class requires start date and end date to be the same too for two accommodation object to be the same.

Ya but i dont know what badges we should add, there's quite a few different one

Ok added

Changed

Okay changed!

This test will fail so i changed it back.

Ok resolved. Thanks!

Resolved.

Resolved

Resolved.

resolved.

Resolved.

Jeanne say for the UI one make it more spread out

Ok i can delete that one whitespace

hmm it works fine leh, maybe after yall merge can try it out first, got any problem we can fix too

oh.......

ok thxtx

cannot do this if not compilation will fail for checkstyleMain. AB3 doing like this too.

Solved

??? i got change wts

i think we should show index in ui

no theres a space.. thats why we use keyword[1] instead or [0] to access "-travelplan'"

I thought name card is the name of the travelplan, which is the travelplan panel? the one that shows the name and date

Oya ok i changed ps

ok changed

Addressbook can be changed to CLI-nic

'serves'

name changed

Seems like this can be final also.

Perhaps the updatedQuantity should be renamed to productQuantity, because it seems like this should be a general constructor that future functions other than updateQuantityForWarehouse can use.

Since it is mentioned in your javadoc that this is meant specifically for suppliers, perhaps u can follow the naming convention that u did for toStringWarehouse. That being said, toStringForWarehouse may be better.

Perhaps this can be renamed to ALLOWED_ARGUMENTS or ALLOWED_ARGUMENT_LIST

I think there should be a \n here

same as above

perhaps its better code quality to explicitly specify the else with a separate if statement.

To do javadocs

comment should be updated as well

i think the naming for this is a bit confusing, at least at first glance, perhaps can change everything to all

I think you can just use list.of() instead of arrays.aslist(String[]{})

ab used to stand for addressbook, now it has no meaning so i think it should be changed

I think you might have forgotton to remove this.

"ui" should be capitalised. "i.e." should have 2 dots.

"set of products" or "set of Product" or "product set" may sound more grammatically correct.

"The retrieved product set will remove this product from the set" sounds a bit inaccurate. Perhaps it can be replaced by just "the retrieved product will be removed from the set"

"The model will also update the warehouse with the new warehouse with the target product deleted." also can be replaced with "the model will also be updated with a new warehouse with the product deleted. "

I think it should be " with a success message".

It might be better to call the feature add product feature. 'addp' is the command word which should be used with the double tildas in my opinion

I guess to make it clearer instead of "at any one time", u can say "in a single add command". will help also when macros can execute multiple at once (if implemented)

perhaps the "(for warehouse only)" shouldnt be within the tildas, same issue repeated below. Also is there a reason for the "+".

not sure if NAME should be in tildas

Yes, It is the case. the latter is the stricter check.

Yup, its just a dummy function for the stub

Yes, thats what I meant.

Thats true, Ill update the example accordingly. Thanks!

Hmm not sure either...full name is originally a public attribute with no getters, and this .fullname is used is several places in the original code as well. Same for the other supplier/warehouse properties.

Yes, thanks for spotting the error

Thanks! will fix it.

Actually both clinic and user macros are part of the {@code storage} thats why they are not in the brackets.

True, will change it!

Good spot! Thanks.

True i'll amend it.

Oh yes. Good spot.

LGTM

For the part about commands only keeping the results from the last occurrence of a specified descriptor, I think it was originally not so much a bug but rather an intended outcome, as there are explicit test cases in the original AB3 to show that multiple descriptors of the same prefix will be accepted without error but only the last will be used. We can do an alternative approach though I would not think its absolutely necessary.

As for the case sensitivity, I guess we can discuss both the case sensitivity of the command syntax (command word/prefixes) and the user-supplied command arguments. For the command word at least, the case should not matter and we can make it case-insensitive to improve user experience, though I would think it's not a pressing issue as we can do without too.

For the redundant strings at the back of commands and the explicit ordering of arguments, it currently applies for those commands that dont actually use prefixes. For those with prefixes, changing it to allow redundant arguments may be a bit cumbersome, since currently all the arguments at the back will just be allocated to the last prefix, and we would require additional command-specific parsing to split the last prefix from the redundant strings if they would otherwise be parsed as invalid format for the last prefix. For those that don't, we can either make it explicit that redundant strings are allowed in the user guide for these commands or just don't accept them. Similarly for the ordering, we can either make these commands accept prefixes as well since they are multi-argument like the rest of the commands so that they disregard order, or we can explicitly state their difference in the user guide.

sure, makes sense

will fix

i wasn't smart enough to think of this at the time

doesn't compile, looks like we both need to retake 2030

yes, it is designed to modify its input arguments. this wouldn't be necessary if java had some semblance of decent features after 14 versions, like pattern matching;

this is how i use bisect in a proper language:


std::string_view x;

std::string_view xs;



std::tie(x, xs) = util::bisect(input, ' ');

if(x.empty()) return { };



if(x[0] == '@')

{

	parse_tags(msg, x);

	std::tie(x, xs) = util::bisect(xs, ' ');

}



if(x[0] == ':')

{

	parse_prefix(msg, x);

	std::tie(x, xs) = util::bisect(xs, ' ');

}

unfortunately this can't be done in java (there's no std::tie equivalent, nor can there ever be). rather than introduce loads of syntactic noise by needing to (a) declare a pair to store the bisectionr result; (b) declare or assign a variable for the first part; (c) declare or assign a variable for the second part, it is more convenient this way.

besides, bisect() clearly documents its mutating behaviour.

for this kind of boolean parameter, i suggest doing something like this:


        return new CommandResult(SHOWING_HELP_MESSAGE, /* showHelp: */ true, /* exit: */ false);

so that it's easier to see what the true and false mean without going into the definition of the class/function.

sm0l style issue but there should probably be a newline here

another small thing but probably it'll be easier to define the commandResult only when you need it (ie. on line 43 instead of 41)

this isn't c89 can you please define the int in the correct place

is this better named currentIndex

is it possible to make this a List&gtIngredientRef> (or a List&gtJsonAdaptedIngredientRef>) or something? feels a bit fragile to be storing it as name (qty) as a string in the json file


return Quantity.parse(words[1])

    .map(qty -> new IngredientReference(words[0], qty);

surely you meant words[0] here since you want the name? (line 39)

can use Mass.grams(10) so you don't need to unwrap the Result

not done yet ah

wait a minute, isn't this file a duplicate of the CommandDispatcher

ups

can we just use String.format for this instead of this stringbuilder nonsense

isn't this just this.isSame((Entry) other)

what's with this monkaMEGA indentation

doesn't this regex mean tag names can't contain spaces?

eh i dun understand why y'all love to copy-paste this equals method with these same useless comments

did you forget that you had Tag::getTagName()

maybe you should make a smol nested helper class for this

pog

less typing. as you know typing places strain on your wrist, which is bad for health <- cwf="C:\repos\nus-cs2103\dashboards-base\contents\cs2103\tp-comments-panels.mbdf"> var is good for health

ok but most of the time, var is used either (a) when the type is obvious, like this:


var foo = new SomeOverlyLongClassName();

// versus:

SomeOverlyLongClassName foo = new SomeOverlyLongClassName();

and (b) when the type is not important, like in this case. explicitly writing Map.Entry<Optional<ExpiryDate>, Quantity> is tedious and doesn't contribute anything to the clarity of the code. </->

Looks good to me 👍. Thank you for your contribution!

Look good to me 👍. Thank you for your contribution!

Looks good to me 👍. Thank you for your contribution!

Looks good to me 👍

Closed by #43

Closed by #38 and #40

ready for merge

ready to merge

Closed by #40

Closed by #38

looks good to me, blah blah etc. etc thumbs up

Closed by #52

ups

Looks good to me 👍

hmm, yea that makes sense. but idk if we’re gonna put some sample data by default like AB3?

but ya either way i think should have some getting started text on that page, but maybe only the first launch bah

i don't actually know why there's a need for regex validation, especially now that the regex is just all ascii.

also why can't i name my recipe お握り

cool

sorry i mean

LoOkS GoOd tO Me! 👍 ThAnK YoU FoR YoUr cOnTrIbUtIoN!

ready to merge

Duplicate of #76

oops

branch is even with master, plz merge

done

ah, this is a good solution.

btw doing closes A, B, C, and D only marks A as being closed by this pr

cool

Maybe Priority Queue for room search should leave it for further version? We could use a arraylist to found the first empty room probably? B'coz priority may need constant update to R/W whenever a room state is changed

I think "next" could be a little vague, coz the user may not know which room they are in, maybe "finds the first free room" could be better?

just minor gramma, "rooms"

good code quality improvement!

I am not so sure why there's a "-", so is it that the user will specifically put an "-" or is it an invalid input

I think this method should be changed with a name getValidpatient and should return a patient as the name suggests. isValidPatient is like a boolean method and should only return a boolean

Mabybe using a switch could be better for readability?

Nice to have an observablelist for getroom

maybe can change to: "there are no room in the app yet, please define no of rooms"

really nice to change to 4.0 --> 3.10

I think it's a bit unclear about the change of room number, is it that room 3 doesn't exist before change or room 3 already exist and we move all patient from room 1 to room 3 and now room 3 has all patient from room 1(previously) and 3?

I think it's better to break the sentence After the fullstop

Just small gramma "AssignedToRoom"

This sounds a bit weird to me. Maybe change it to "All patients are listed" or " list all patients"

I think later when you complete the searchroom rmb to remove the "%1$s" as it's a list of string

Good change to modifiableRoomList as a diff to unmodifaibalbeRoomList

good assertion! If the targetroom is null, it will be prehandled by the commandexception

I think instead of letting the model to handle deleteTask, the deletetaskcommand class should handle it instead for abstraction

Maybe add a success case for test?

oh then that's ok I guess

hmm I think the same patient object should still have the same temperature

Nice job to separate to more cases!

remember to remove the system.out.print after doing the "actual" testing

Maybe consider "returns" instead of "gets" for javadoc consistency?

yup! SearchPatientDescriptor is a better name

will focus on the style!

yup, can isolate it to be another method

yup, can change to "search a patient or a list of patient ..."

sure

sure!

This is really a good idea! Thanks for bringing it up

YUP!

Hmm.. I feel both method name is ok

Definitely true

I will change it to "Search a patient or a list of patients with specific criteria"

sure!

good sugguestion!

The main reason I put this is just because I feel that it is not necessary to output a list when there is only one item

Yup! Thanks for the advice!

the substring(2) is to substract away the header ("n/")

I think getPreamble will work just fine!

actually I think getPreamble cannot work since the command is searchpatient n/alex, so there isn't a preamble for the command for now

Sure!

Yup, will take note of the gramma

I think as of now, we will save the UI for v1.3 for task, so v1.2 we will juz display the result in the bot's response

I will add more success test case in v1.3

yup

I am not sure whether we need to leave a line also, but thanks for the "s" reminder!

Sure!

Since ParserUtil.java is still there, is it better to keep this test file instead of deleting it?

What's wrong with this test

Does the position of the unnamed parameter matter?

How does the program behave towards these commands:

edit -n JohnDoe 1

edit1 -n JohnDoe

Just to justify my curiosity, can a command have multiple unnamed parameters?

I think this should be AddCommand.COMMAND_WORD instead of "add", the same for other commands

Although these test classes will be changed in McGymmy, is it better to keep them just for this PR to make sure that the new parser is working properly with the old AddressBook test first?

Same comment as AddCommandTest.java

Maybe add some more tests for the old address book's logic, to make sure that it works exactly as expected as the old parser?

I think naming it toString is enough

I think naming it getCalories is enough

I think the first letter of the string should be capitalized to be the same format as other files

Inconsistent verb tense: In some files, the string is present simple tense whereas, in other files, it is infinitive.

Maybe adding an example here too?

Can you add addCurrentStateToHistory(); in this line so that undo command can refer to this state later

Is it better if you implement this test case in this PR too?

Since you have already had an if statement below, I don't think this line is needed

I think changing it to this will make the code shorter:

'''

this.date = null;

try {

date = ParserUtil.parseDate(date);

}

[rest of the code]

}

Is there any case where this test can really get an exception?

Instead of using null, how about declaring a subclass of FoodContainPredicate that always returns true, then use

FoodContainsKeywordsPredicate foodPredicate = foodPredicateParameter.getValue().orElseGet(THAT_CLASS_NAME::new]);.

The FoodContainsKeywordsPredicate has already included NameContainsKeywordsPrecdicate and TagContainsKeywordPredicate.

yea this works too

object equality is intended, as I was checking if fridge and expected fridge contains the same elements. I have overridden the equals method for fridge class

Ok I will change it that way

Oops, I forgot to implement it. I will implement it in the next commits

Ok I will change it

I think we should keep it that way to prevent potential typos. Instead of that, we can add a comment at the end of the line to explicitly state what Carbohydrate.class.getName() is

I was just changing the name of the class. I haven't changed any of its implementations.

Ok I will change it

Fixed

Actually, we cannot call this.class before the object is initiated. Therefore, this.class.getName() cannot be put in either Macronutrient's constructor or a static method.

I think one alternate option is that we can use this.class.getName() as a replacement for the macronutrientType attribute

Got it!

Fixed

The tag search is already case sensitive.

Ok I will change the name

Isn't making the tag search case sensitive better for categorizing food items? The user can search for exactly one tag that they want.

Haha so i mark this as resolved now

Thanks =))

Even if the string is in the correct format, it is still not guaranteed that it can be parsed. For example, 31-31-2020. We still need the empty catch clause either way

I remembered them said empty catch clause should be avoided, but if there is no other way to avoid it, we should comment why. I think putting a comment there is good enough

Added

I move those lines in EditCommand, TagCommand, and UnTagCommand ModelManager#setFood instead since they all call this method

I've added one assertion in the latest commit

Done!

LGTM.

The CI test says that you are missing the shadow plugins

I think your use case have the same id as sean's.

LGTM.

Might also add an extension like this:

find -all [keyword 1] [keyword 2] ... to find foods that match all of the keywords

find -some [keyword 1] [keyword 2]... to find foods that match some of the keywords

I think this would create potential bugs. For example, assume there are food items with the same name, fat, carbs, protein, date but different tags in the fridge. Then you filter a tag name and delete the filter result. It might delete the wrong food item because List#remove(E e) only removes the first occurrence of e.

To prevent this, I think you might need to update the Food#equals method

Change according

I think you can do smth like what Kamil and I did and abstract out the Parsing part? This will remove the McGymmyParser part completely and make the diagram less complicated

Fixed!

Do we want an option to find before/after a certain date? i.e. show all foods created before/after a certain date?

Or we can put this in another PR/not do this at all.

I think we should create another pr.

If the user calls list multiple times, what should be the expected behavior of the program? Should it allow undoing the same number as the number of list command, or just 1 time?

bug found

What is the bug

Should be added to Table of Contents as well if we're adding in a new command list

The table of contents is actually generated by GitHub with


* Table of Contents

{\:toc}

With this addition we will have two copies of the TOC on our documentation website.

While editing this, could you also change the spelling of "Travelling Businessman" in "Glossary" to have a capitalized "M"?

Minor point, but can this be changed to "E.g." instead of "eg" with the period.


            + "client edit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [c/COUNTRY] [tz/TIMEZONE]\n"

Should this be checked with requireNonNull(predicate)?

String can be put into a constant for clarity

Similarly, is requireNonNull needed here?

This check seems to be carried out in ParserUtil already


    /** Client command in the form client view index, where index points to the index of the client at current location

    of the rendered */

Should fill in the javadoc here


    /** Client command in the form client view index, where index points to the index of the client at current location

To be more inline with the coding standards

Could you change the class and file name to ClientViewCommandParser? I will be updating the ones for Find and Delete in a future PR

Missing javadoc for return here too


    /** Client command in the form client view index, where index points to the index of the client at current location

Pls have the space there 😦

This should probably be moved over to Country.java to be more consistent with the other classes.

In AddressBookParser, the arguments are passed in as return new ClientNoteAddCommandParser(tagNoteMap).parse(arguments);. Shouldn't the preamble consist solely of the integer without the command word of client note add?

Inside ClientEditCommandParser, the index is parsed as such index = ParserUtil.parseIndex(argMultimap.getPreamble());

There are helper functions assertParseSuccess and assertParseFailure that are used in testing of the other parsers, would it be applicable in this case as well?

Wouldn't it be better to use NOTE_CONTENT_1 to show that there will definitely not be a difference in the input to the two notes?

Is there a reason that this is instantiated differently from the rest?

Similar to above

Should this be used instead to check for validity of a date string? Then we could do away with the regex since it doesn't actually filter out 31-Feb.

Maybe idx1 here since it's clientNote1

Is there a reason clientNote1 is NOTE_CONTENT_2?

I'll update for delete but leave find as it is for now, I think someone else is working on find?

I think we can leave that to the refactoring since the hashmap currently uses String as the key

Initially it was because ClientUtil.java needed to build the command given the client's details, I changed the implementation of getClientDetails to explicitly use getCountryCode() so this function isn't currently in use now. I thought it would make sense to have countryCode since that is the value passed into the object like the other fields.

Fixed

ok, i've added it in.

actually, i just checked, it's supposed to be part of my other issue LOL

possible, I initially put it as an enum but it seemed too different from the rest of the code base. What do you think @qwoprocks

yea forgot to change it when i updated to mingchong's changes 😦

While updating this, could you add in numbering for the use cases as well? Then this statement can refer to other use cases as an example.

Does #121 branch continue from this PR? If it does this PR can be closed.

Resolved in #117

Resolved in #119 #131 #137

Resolved in #119

Resolved #134

Not relevant. Note interface is no longer being created.

Resolved #134

Updated in collaborative notes.

Currently have "([A-z ]+) ((\d+)?([ \w/]+)?)" as the regex which tries to separate commandWord from arguments through detecting either a number or a prefix. Requires " " to be padded to the end but this fails for "client find KEYWORD".

think there's a typo here, eva.jar -> MyFitnessBuddy.jar

should be the original persons, this MIT license file no need to edit.

need to change the logger message also

is this still supposed to be getAddressBook() or getPerson()? Only the Javadocs header is changed but not the actual code.

Refactor this method

hmm now calorie command no need dates?

need a Javadocs header here to explain what this class is for.

javadocs header for the class and the methods, just copy, paste and edit from other existing ones.

refactor the ReadOnlyAddressBook interface

refactor this whole interface class

javadocs header here

javadocs header

refactor this method

Need to edit this javadoc

This one should be Stopping My Fitness Buddy haha

this whole class refactor to MyFitnessBuddyParser

refactor this class to MyFitnessBuddy

refactor this class to ReadOnlyMyFitnessBuddy

Javadocs header

i will wait for @wayne987 PR then i will merge to prevent conflicts.

can sync your fork with the team repo again? so the CI can pass

left @wayne987 part

yeap is correct

closed without merging

LGTM

I will leave this issue open if there's anything more to add. Link a new PR to it if have.

Still rewriting all the test cases code, CI will fail

Weight is added using the 'add' command with a prefix 'w/', additional fields will be removed in another PR.

Current UI modifications for MVP

@wayne987 please review thanks

Closed without merging, code not required

CI is expected to fail

Before Fix:

After Fix:

Looks good to me.

Calorie Stats:

Weight Stats:

Will change the miscellaneous stuff (background colour etc) later

will it be better if theres another separate Statistic class that calculates all the required data for calorie and weight instead?

no calculation involved here, all the required data is pulled from Observable List

Dark Theme for Charts:

Already done, just need to merge my previous stats PR #89

I would recommend that this will be merged first

Merge this PR only after PR #89 because this branch is merged with commits from PR #89

Merge only after PR #103; need to verify sorting for charts

Changed to Bar Chart for calorie stats for better visualization:

I think for this, it could just be "User enters the required details" since implementation details are not needed for use cases

Same as the above. Instead of this, perhaps you could try "User requests to cancel the command"?

I think for this, it could just be "User enters the required details" since implementation/UI details are not needed for use cases.

Same as above. Perhaps you could try "User requests to cancel the command" instead?

I believe bullet points are required for indentation here as well.

Perhaps a new indentation would be good here?

is there a typo here?

Might be better to mention that this command deletes everything before and up to the given date. It may be misunderstood to just delete visits on that date itself.

What might this suppress warning be for?

There shouldn't be a space after the method name. Also, since this method deletes multiple visits, maybe calling it deleteVisits would be more suitable.

This functionality could perhaps be moved into the for loop above? Then there would not be a need for an additional ArrayList to keep track of the visits to be deleted.

argMultimap.getPreamble().isEmpty() should be !argMultimap.getPreamble().isEmpty(), otherwise the code fails.

Only this part causes errors; the other comments are queries/small formatting errors.

The JavaDocs for this Predicate could be clearer as this Predicate is not as straightforward as the others.

Might be better to name the conditions separately with informative names as this line of code can get confusing.

Now that there are three parameters for the constructors, perhaps it could be better if each parameter is tested for NullPointerException in a separate method.

Typo here. Shouldn't be nullLocation but instead the parameter that is null in this method.

Shouldn't date be required to be non null as well?

Could this be moved to the ModelPredicate class as the predicates are being stored in that class at the moment?

Is there a typo in the method name?

Typo in the word 'where'

Perhaps Generating could be used instead of Listing

I think for this, referencing the index rather than id is required. I believe the current master branch has an example of this.

Yes, these methods should already be functional barring unforeseen bugs.

The method was added for the following reasons:

The Person and Visit classes both have these two methods in Model - getFiltered[x]List() and updateFiltered[x]List() where x is either of those classes. As the InfoHandler class requires the getFilteredLocationList(), I felt it was apt that updateFilteredLocationList() was added as well.
Also, the addLocation method in the ModelManager requires the updateFilteredLocationList() as well.

As for the test above, the function is required to be overwritten for the ModelStub to be created.

Done

Issues

Format

When creating an issue, try to specify the part of the project the issue is meant to be working on by using square brackets in the title. If the issue does not specify anything, it is assumed to be implementation-based, i.e., related to modifying AB3/VirusTracker code.

Example: [DG] Add UC01 and UC02 indicates that this issue works on adding user cases 01 and 02 to the developer guide.

Labeling

Mandatory label:

priority.* Indicates the priority level of the task. Has three levels, low, medium and high.

Apart from the mandatory priority label, you may include other labels to make it easier to search and locate issues. Feel free to add any labels, but please ensure no similar label already exists.

Pull Requests

General note: PRs can only be merged only when two or more other people have reviewed and approved of the merge.

Format for PR

When creating the PR, please state which issues the PR closes on the last line of the description.

Commit message: keyword #xx, keyword #yy, keyword #zz for multiple issues

keyword refers to any one of the following three words, close, fix, resolve.
- Using these keywords will cause the issue to be automatically closed once the PR is merged successfully.
- _Note: Other tenses for the above words could be used as well, such as closes or closed, but let us standardise using the
  
  imperative form of the words above._
#xx references the issue number, where xx is the number. For example, xx = 10 will reference issue number 10.

Example: xx = 30


...PR description here



Close #xx

The above will close issue 30 upon the successful merging of the PR.

The actual form of #xx is not used in this comment as it would reference actual issues. Please refer to the PRs page for more examples.

The user cases have been added, and this issue will be closed

This user story has been added, and this issue will be closed.

Location classes have been completed, statistics classes will be moved to v1.2.

A new LocationHandler class should be created to be in charge of handling the statistics.

I've updated the title accordingly to avoid confusion

Rather than LocationHandler, we can instead create an InfoHandler class which additionally handles people and visits

Issue can be closed, InfoHandler class has been implemented with relevant methods.

Will removing the "find Grab" example make the table look neater?

Are we missing the details for adding an expenditure?

Perhaps "Temasek Hall" is too specific to NUS? Users who are not from NUS may not understand what it means. "Daily Expenses" might be a better example. I noticed the same issue in several other places.

Will it be more concise to use "budget" instead of "budget book"? I noticed the same issue in several other places.

Will it be better if "must be a positive integer" is bolded to draw users' attention to this restriction?

Same issue as above regarding the bolding of "must be a positive integer or double with a maximum of 2 decimal places". There seems to be two spaces between "of" and "2".

Same issue as above.

Perhaps it might be more cohesive to capitalise "school fees"? I noticed the same issue in several other places.

Yup, let's use "budget" instead of "budget book" as discussed. Good catch 👍

There is a missing space between the and LogicManager.java.

Perhaps DevOps should be separated with a white space to follow the title?

Should this be ExpenditureCard instead?

Perhaps it will be more OOP if there is an additional private method to get the the budget of a certain index.

Same issue here.

Perhaps it is more appropriate if the method "isValidBudgetName" is changed to "isValid"?

Perhaps it is more appropriate if the argument "budgetName" is changed to "name"?

Perhaps the naming should be "isExpenditure"?

Is this condition redundant?

Perhaps the sentence should start with "Executes"?

Same issue here

Perhaps the class diagram should have a caption "Figure 3.4.1..."?

Should the class objects be wrapped using ``?

Same issue here.

If you want, you can re-upload your photo so that it scales correctly. @sogggy

The examples for adding an expenditure is not in the correct format.

Might want to remove this line since everyone else also did so

You may want to add a (written by: AUTHOR) statement before the part that you wrote because I think they want to see who wrote what.

Whoops, I had changed Year to only allow digits, so this might fling an exception since it's expecting only "4"

Just a minor nitpick for neatness, but I think these 2 lines could be on the same level of indentation as line 64.

Since year is just a String now, toString() could just return year itself. But this is also really minor.

Perhaps you could change "person" to "student".

I think you can remove these 2 lines aha

Should this be ClassVenue.MESSAGE_CONSTRAINTS?

Should this be ClassTime.MESSAGE_CONSTRAINTS?

Should this be Fee.MESSAGE_CONSTRAINTS?

Should this be PaymentDate.MESSAGE_CONSTRAINTS?

Why is there a need for this? I believe it was the same way in the Tag implementation in AB3, since when these are put together there is another module with its method to put a space between tags.

Will you be adding them withClassVenue/ClassTime/Fee/PaymentDate for Bob?

Whoops, I actually meant the space at the back of the closing square bracket.

Perhaps you could test for multiple predicates too.

One suggestion would be to create your school/year predicate too and then create a FindStudentDescriptor from it, then have a method in testutils.StudentUtils that converts it into "n/... s/... y/..." form, similar to how it is done in parseCommand_edit(). The outcome would be:

FindCommand.COMMAND_WORD + " " + StudentUtils.getFindCommandDetails()

Additionally, if you are using prefixes, you might want to refer to them by how they are defined in CliSyntax instead of magic literals.

Year is actually a String now that accepts alphanumeric characters. Hence I think we should relax the requirements to be one where it returns true if student.getYear().year contains the keyword (e.g. year could be a String and it is matched using StringUtils::containsWordIgnoreCase).

That way, if you search "4" you could get those who put "Sec 4", "sec 4" or "Secondary 4" if the user is inconsistent.

It also means you will be less likely to land an IllegalArgumentException if the user parses an invalid string since right now FindCommandParser currently has to call Year#new to construct this.

What is the equals method used for?

Making the Lists public final still means you can add keywords to the list at will, you just can't reassign keywords to a new List object. Is that what you mean to do?

does this mean that if you search "sec 3" you get all that either match "sec" or match "3"? (e.g. you get sec 1-4 and p3, s3)

Yeah I think your current implementation is fine then

Would it be more helpful if we made it look only for words that contain all the keywords (even incomplete ones)? (i.e. AND search)

For example it would be like:

String year = student.getYear().year.toLowerCase();

return keywords.stream().map(String::toLowerCase).allMatch(year::contains);

Looks good! Perhaps one suggestion would be to call editAdminDescriptor::isAnyFieldEdited so we can just create the new student using student.toEdit().getAdmin().

Really damn minor note but you could probably just use Optional.ofNullable(details).map(Collections::unmodifiableSet)

Oh ya horh

add - Alex/Hogan

edit - Vaishak

find - Ying Gao/Choon Siong

After we merge this we should merge v1.2 branch into master already

Nabei I test all the methods this bot still say less coverage

My concern is that IP, IB, MOE mainstream tracks have different naming in their levels. Furthermore, there could be other level naming, for eg a tutor teaching music or arts may have different levels naming for their students.

I think this is not too bad a problem since our primary target was pri/sec/jc tutors so if we frame our target audience that way we still can meet their requirements

Looks like I will have to wait for #72 to be merged before I can pass these test cases

See #53

Functionality already exists

Basically what we've been doing all along

Possible improvements for future

JsonAdaptedQuestion is a map&gtquestion, boolean> instead of a string
House for each question in a JavaFX VBox

Perhaps you could also look into making ClassTime and Student implement Comparable so we can sort students in the filteredList in order of who goes first.

Implementation: Give a reminder of students who need rescheduling

See #101

Are you not gonna include sorting anymore? I think it's alright to have the sortFilteredStudentList method, I was just asking to rename the other methods back to [...]Person[...]

My man... Did you forget to stage and commit your activity diagram pngs

Maybe change the sections (deliverables, contacts, meetings) to their respective epics, following our meeting docs? E.g. this line of code can be "[EPIC] As a Product Manager, I can track my product’s development so that I can work better towards production deadlines. (Deliverables)"

Noticed you left out type of Product Managers in here and elsewhere (e.g. "Product Manager who needs to be aware of changes in description of deliverables"). I believe we can leave these out for now. Just a note.

For consistency, can we change to just "mark deliverables as completed"? (I'll update the changes on the docs)

Can we change to small caps 'm' for 'Minimise'?

In here and elsewhere, should we follow the user stories as closely as the gdoc since it's more or less cross-checked among ourselves? i.e. for this line of code, can it be 'contact the right person if needed'? Alternatively, 'locating the right person easily' would work, since this user story is about editing the POC.

Should we take out "(completed deliverables / total deliverables)" since it may lead to confusion? It may be misunderstood as completed deliverables or total deliverables instead of over. Alternatively to explicitly state "completed deliverables out of total deliverables".

For consistency, can we have "keep them up-to-date" for the 'so that' portion?

Can we have back the 'remember and retrieve important information' under 'so that' portion?

Can we capitalise the 'i' in 'keep any data that i want'?

Can we have plural 'contacts' instead of 'contact' under 'so that' portion?

Did you miss the epic "As an inexperienced or forgetful Product Manager, I can refer to a user guide as I’m using the app so that I am able to use it as intended"? The user stories in this epic are not reflected.

Here and elsewhere, noticed the numbering isn't correct, but I believe markdown solves this automatically. Have to check again? Just a note.

In here and elsewhere, for consistency, can we ensure all the lines end with periods (.)?

Can we ensure the use case IDs are in consecutive order, i.e. this should be UC11 and delete contact should be UC12?

Can we change to singular 'Deliverable'? (side note: we may need to redefine this keyword. Personally it sounds slightly vague though I know this definition was taken from online).

Should we leave this keyphrase out since I don't think we use it anywhere?

Can periods be included for all the epics too?

Have seen that the rest have periods now. How about this line too?

I believe you added the 'so that' portion wrongly here. It should be for the "view my contacts and their relevant details" user story under EPIC B. Could you help to change that?

Could we change this to "view a helpful popup"? Just a small grammar error.

I think your suggestion would work for now.

Can we fix the typo here? Maybe in the next big commit for UG. Just to note.

Maybe a more meaningful description?

I made two fields for Deadline class. One a String, and another a LocalDateTime. We can use the latter for comparison, and leave the former as it is for string rendering (y)

I just tried and the whitespace doesn't get reflected on markdown. The current implementation should work alright (there's an illusion of whitespace). Thanks for the suggestion 😸 !

Will create another PR for this commit.

No need to review/merge.

Checks failing due to Edit command not available yet.

Fixes #3 and #5

Change the "/dead" token to "/by" and "/desc" to "/d"

Amend to use the correct constructor

To check with prof regarding the changes to be made to monitor code coverage

Minor issue, remember to capitalize Supplier and line 276 and 280 as well.

Same issue, minor typo for Supplier

Capitalize also

Similar to comments left on UniqueWarehouseList, should this be removed instead?

Similar to comments left on UniqueWarehouseList, might want to change to replaceSupplier

Minor issue, capitalise Suppliers

Capitalise Suppliers here

Would this mean that 0 is acceptable? Or is isNonZeroUnsignedInteger meant to be a stricter check?

Oh I see that it is being used for index and quantity separately in another file.

Alright got it!

Message should be "Deleted Warehouse: %1$s" instead

In the 3rd sentence:

Should add a space between "The" and edit

In the 4th sentence:

Could be two different way of expression in "the last type specified will use processed"

The rest are well described.

I cant figure out why this paragraph is bold in the file. (Can click the three dots at the top right then click view file)

Minor issue:

Can make warehouse plural as well in this sentence - "Furthermore, another alternative considered would be to create separate commands for warehouse and suppliers respectively."

Will there be a {@code userMacros}? I'm not too sure about how this component of the code.

Maybe "Problem encountered while reading..." or "Unable to read from..." would be better here

Same as above

I think there is missing a word here, should be "original input string when no macro is used"

Can remove extra line here

Oh {@code UserMacros} exist here, the one on top can include too!

Represents 'an' alias

Oh alright! 👍

Hmmm... Okay I'm including these line breaks,

Thanks for pointing it out, I do agree with you and have specified in the next commit!

Oh yes good spot, these were written before we finalized the changes in our commands

Yea this is outdated now, I have fixed it earlier. No wonder I couldn't find it hahaha

Okay as per user guide, we only have Tag for products so yes this should be Remarks!

It shouldn't be remarks either, it would look like this now and should be pretty straightforward without explanation. We can improve on it at a later time because UML is still rather unstable.

Fixed!

I'll update accordingly depending on how we are integrating Macro feature into all other features!

I've broke it up to two parts so the warehouse only doesn't cover the front few prefixes.

I've put it in tildas as it is a param

This makes sense, I've edited it accordingly thanks!

Approve for testing purpose to see the badge shows CI fail

Test successful, icon changed to failing.

@zhengweii Revert back to pass CI